Что такое заголовок протокола

Обновлено: 28.06.2024

Как работает WWW (всемирная паутина, веб) в двух словах:

  • браузер пользователя (клиент) отправляет на сервер запрос с адресом сайта (URL);
  • сервер получает этот запрос и отдаёт клиенту требуемый тому контент.
  • Заголовков запроса/ответа;
  • Тела запроса/ответа.

Сначала идёт список заголовков, затем пустая строка, а затем (если есть) тело запроса/ответа.

2. Сервер принимает запрос и отправляет ответ:

3. Браузер принимает ответ и показывает готовую страницу

  • Метод, которым будет запрошен контент;
  • Адрес страницы;
  • Версию протокола.

GET — это метод (глагол), который мы применяем для доступа к указанной странице.
GET является самым часто используемым методом, потому что он говорит серверу о том, что клиент всего лишь хочет прочитать указанный документ. Но помимо GET есть и другие методы, один из них мы рассмотрим уже в следующем разделе.

После строки с указанием основных параметров всегда следует перечисление заголовков, которые передают серверу дополнительную полезную информацию: название и версию браузера, язык, кодировку, параметры кэширования и так далее.
Среди всех этих заголовков, которые передаются при каждом запросе, есть один обязательный и самый важный — это заголовок Host . Он определяет адрес домена, который запрашивает браузер клиента.

Больше всего здесь интересен именно код состояния, он же код ответа сервера.
В этом примере код ответа — 200, что означает: сервер работает, документ найден и будет передан клиенту. Но не всегда всё идет гладко.
Например, запрошенный документ может отсутствовать или сервер будет перегружен, в таком случае клиент не получит контент, а код ответа будет отличным от 200.

  • 404 — если сервер доступен, но запрошённый документ не найден;
  • 503 — если сервер не может обрабатывать запросы по техническим причинам.

После стартовой строки следуют заголовки, а затем тело ответа.

Работа с заголовками в PHP

  • Получение тела запроса;
  • Получение заголовков запроса;
  • Добавление/изменение заголовков ответа;
  • Управление телом ответа.

Разберём всё по порядку.

Получение тела запроса

Тело запроса — это информация, которую передал браузер при запросе страницы.
Но тело запроса присутствует только если браузер запросил страницу методом POST .
Дело в том, что POST — это метод, специально предназначенный для отправки данных на сайт. Чаще всего метод POST браузер задействует в момент отправки формы. В этом случае телом запроса будет содержимое формы.

В PHP-сценарии все данные отправленной формы будут доступны в специальном массиве $_POST . Более подробно об этом написано в следующей главе, посвящённой формам.

Получение заголовков запроса

Пример, как получить предыдущую страницу, с которой перешёл пользователь:

Добавление/изменение заголовков ответа

В PHP-сценарии можно управлять всеми заголовками ответа, которые попадут к пользователю вместе с контентом страницы. Это возможно, потому что PHP работает на стороне веб-сервера и имеет с ним очень тесную интеграцию.
Вот примеры сценариев, когда пригодится управление заголовками ответа:

Заголовки ответа нужны для выполнения множества важных задач.
В PHP есть функция для отправки или смены заголовков: header() .
Она принимает имя и значение заголовка и добавляет его в список из всех заголовков, которые уйдут в браузер пользователя после окончания работы сценария.
Например, так выполняется перенаправление пользователя на другую страницу:

За переадресацию отвечает заголовок с именем Location , а через двоеточие задаётся значение — адрес страницы для перехода.

Важное замечание по использованию заголовков
Есть одно ограничение: заголовки нельзя отправлять, если пользователю к этому моменту уже отправили любой контент. То есть, если показать что-то на экране, например, через функцию print() , то после этого заголовки поменять уже не получится.

Управление телом ответа

Всё, что PHP выводит на экран, является содержимым ответа. Иными словами, вызовы функций print , echo или показ текста через шорт-теги являются телом ответа, которое попадает в браузер пользователю.

Параметры запроса

На сайте дневника наблюдений за погодой мы сделали отдельную страницу, чтобы показывать на ней информацию о погоде из истории за один конкретный день. То есть страница одна, но показывает разные данные, в зависимости от выбранного дня.
Также пользователи хотят добавить в закладки адреса страниц с нужными им днями. Получается, что имея только один сценарий сделать страницу, способную показывать дневник погоды за любой день невозможно? Вовсе нет!

Из чего состоит URI

Параметры запроса — это как бы дополнительные атрибуты адреса страницы. Они отделяются от имени страницы знаком запроса. В примере выше параметр запроса только один: date=2017-10-30.
Имя этого параметра: date , значение: 2017-10-15 .
Параметров запроса может быть несколько, тогда они разделяются знаком амперсанда: ?date=2017-10-15&tscale=celsius

В примере выше указывается два аргумента: дата и единица измерения температуры.

Параметры запроса как внешние переменные

Теперь в адресе страницы используются параметры запроса, но какая нам от этого польза? Она состоит в том, что если имя страницы вызывает к исполнению соответствующий PHP-сценарий, то параметры запроса превращаются в специальные внешние переменные в этом сценарии. То есть, если в адресе присутствуют такие параметры, то их легко получить внутри кода сценария и выполнить с ними какие-нибудь действия. Например, показать погоду за конкретный день в выбранных единицах измерения.

Получение параметров запроса

Если есть внешние переменные, то как их прочитать?
Все параметры запроса находятся в специальном, ассоциативном массиве $_GET , а значит сценарий, вызванный с таким адресом: day.php?date=2017-10-15&tscale=celsius будет иметь в этом массиве два значения с ключами date и scale .
Запрос на получение данных за выбранный день выглядит так:

В первой строчке примера выше мы получаем значение параметра date , а если он отсутствует, то используем текущую дату в качестве выбранного дня.
Никогда не полагайтесь на существование параметра в массиве $_GET и делайте проверку либо функцией isset() , либо как в этом примере.

В этом задании вы сможете потренироваться использовать $_GET .

Формирование URI с параметрами запроса

Иногда нужно совершить обратную операцию: сформировать адрес страницы, включив туда нужные параметры запроса из массива.
Скажем, на странице погодного дневника надо поставить ссылку на следующий и предыдущий день. Нужно также сохранить выбранную единицу измерений. То есть необходимо сохранить текущие параметры запроса, поменять значение одного из них (день), и сформировать новую ссылку.
Вот как это можно сделать:

Разбор заголовков различных протоколов (заголовки Ethernet, IP, TCP, UDP)

В этой статье мы рассмотрим разбор заголовков различных протоколов. К ним относятся заголовки данных Ethernet, заголовки данных IP, заголовки данных TCP и заголовки данных UDP.

Инструменты / сырье

инструмент захвата Wireshark

Метод / шаг

Сначала мы вводим разбор заголовка данных Ethernet. Длина заголовка Ethernet составляет 14 байтов. В основном это: адрес назначения занимает 6 байтов, адрес источника 6 байтов и тип 2 байта.

 ( ,IP,TCP,UDP )

Затем мы выполняем анализ захвата пакета через wireshark, чтобы убедиться, что длина заголовка Ethernet составляет 14 байтов. Из анализа wireshark видно, что это 14 байтов.

 ( ,IP,TCP,UDP )

Ниже мы представляем анализ заголовков данных IP. Детальный анализ:

Версия (4 бита): используется для определения версии протокола IP. Наиболее распространенными являются 4 и 6, которые представляют IPv4 и IPv6 соответственно.

Тип услуги (8 бит): длина 8 бит. 8 бит определяются бит за битом следующим образом. PPP DTRC0PPP: определяет приоритет пакета. Чем больше значение, тем тяжелее данные.

010 Немедленная отправка 011 Flash 100 Переопределение Flash 101 CRI / TIC / ECP (Перевод для этого слова не найден) 110 Управление сетью

111 Network ControlD Delay: 0: Normal 1: Задержка настолько мала, насколько возможно T Пропускная способность: 0: Normal 1: Максимально возможный трафик R Надежность: 0: Normal 1: Надежность настолько велика, насколько это возможно M Стоимость передачи: 0: Normal 1 : Стоимость как можно меньше. Последняя цифра зарезервирована и всегда равна 0.

Общая длина (16 бит): Общая длина здесь относится к сумме длины заголовка и длины данных. Единица измерения - все еще байты.

Максимальное значение, которое может представлять 16 бит, составляет 65535, поэтому максимальная длина дейтаграммы IP может достигать 65535 байтов. Однако, поскольку максимальный MTU (максимальная единица передачи) Ethernet составляет 1500 байтов, если протокол IP работает в Ethernet, он столкнется с ситуациями, требующими фрагментации.

Флаг (3 бита): полезны только первые 2 из этих 3 битов, средний бит представляет DF (не фрагментировать), а младший бит (самый правый бит) представляет MF (больше фрагмента).

Если MF равно 1, это означает, что за этой дейтаграммой IP стоит фрагментированная дейтаграмма, а когда MF равно 0, это означает, что текущая дейтаграмма IP является последней дейтаграммой в этой группе.

Смещение среза (13 битов): в этом поле указывается положение каждого среза в исходной дейтаграмме IP, когда датаграмма IP превышает MTU и разбивается на несколько секций. Исходный источник этого смещения является источником части данных исходной дейтаграммы.

Время жизни (8 бит): длина 8 бит. Когда передается IP-пакет, этому полю сначала присваивается определенное значение. Когда IP-пакет проходит через каждый маршрутизатор по пути, каждый маршрутизатор по пути уменьшает значение TTL IP-пакета на единицу. Если TTL уменьшается до 0, IP-пакет отбрасывается. Это поле предотвращает непрерывную пересылку IP-пакетов в сети из-за петель маршрутизации.

Протокол (8 битов): определяет протокол, используемый верхним уровнем. Ниже перечислены наиболее часто используемые номера протоколов:

1 ICMP 2 IGMP 6 TCP 17 UDP 88 IGRP 89 OSPF

Проверка заголовка (16 бит): используется для проверки правильности заголовка IP, но не включает часть данных. Поскольку каждый маршрутизатор должен изменять значение TTL, маршрутизатор будет пересчитывать это значение для каждого проходящего пакета.

IP-адрес источника (16 бит):

IP-адрес назначения (16 бит):

Всего 20 байтов формируют заголовок дейтаграммы IP.

 ( ,IP,TCP,UDP )

Затем мы собираем пакет через wireshark и анализируем его, и видим, что длина заголовка IP-данных составляет 20 байтов.

 ( ,IP,TCP,UDP )

Ниже мы представляем анализ заголовка данных протокола TCP, длина которого составляет 20 байтов. Детальный анализ:

Порт источника (16 бит), порт назначения (16 бит).

Порядковый номер (32 бита), который указывает последовательность отправленных дейтаграмм.

Номер подтверждения (32 бита), порядковый номер следующей дейтаграммы, которую вы хотите получить.

Длина заголовка данных протокола TCP (4 бита) указывает, сколько 32-разрядных слов включено в заголовок TCP.

Следующие 6 битов в настоящее время не используются,

ACK: бит ACK установлен, чтобы указать, что номер подтверждения действителен. Если ACK равен 0, датаграмма не содержит информации подтверждения, и поле подтверждения пропускается.

PSH: указывает данные с флагом PUSH. Поэтому получатель запрашивает, чтобы датаграмма была доставлена ​​приложению, как только оно прибудет, без необходимости ждать, пока буфер заполнится, перед передачей.

RST: используется для сброса неправильного соединения из-за сбоя хоста или по другим причинам. Его также можно использовать для отклонения недопустимых датаграмм или отклонения запросов на подключение.

SYN: используется для установления соединения.

FIN: используется для разрыва соединения.

Размер окна (16 бит) указывает, сколько байтов может быть отправлено после подтверждения байтов.

Контрольная сумма (16 бит) установлена ​​для обеспечения высокой надежности. Он проверяет сумму заголовка, данных и псевдо-заголовков TCP.

Срочный указатель (16 бит), который является смещением, и значение в поле серийного номера добавляется для указания порядкового номера последнего байта срочных данных.

Вышеуказанные 20 байтов составляют основной заголовок протокола TCP.

Отсюда можно получить алгоритм: общая длина заголовка обычного протокола TCP = заголовок данных Ethernet + заголовок данных IP + заголовок данных протокола TCP.

 ( ,IP,TCP,UDP )

Ниже мы все еще используем wireshark для анализа захвата пакетов и проверки парсинга.Мы видим, что заголовок данных протокола TCP составляет 20 байтов.

 ( ,IP,TCP,UDP )

Ниже мы представляем заголовок данных протокола UDP. Он занимает всего 8 байтов. К ним относятся:

Исходный порт (2 байта), порт назначения (2 байта).

Длина (2 байта), общая длина пользовательской дейтаграммы UDP, в байтах.

Контрольная сумма (2 байта).

Из этого можно сделать вывод, что общая длина дейтаграммы протокола UDP = длина дейтаграммы Ethernet + заголовок данных IP + заголовок данных UDP.

 ( ,IP,TCP,UDP )

Ниже мы используем wireshark для проверки захвата пакета. Вы можете видеть, что длина заголовка данных UDP составляет 8 байтов.

Давайте взглянем на этот протокол через призму нашей профессии. В первой части пройдёмся по основам, посмотрим на запросы/ответы. В следующей статье разберём уже более детальные фишки, такие как кэширование, обработка подключения и аутентификация.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.


Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:


Методы

GET: получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

POST: используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

PUT: обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE: служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

3xx: Перенаправление

  • 301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
  • 303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
  • 304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

  • 501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
  • 503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.


Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Формат запроса

Запрос выглядит примерно так:

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Обычный статус выглядит примерно так:

Заголовки ответа могут быть следующими:

Наиболее часто используемый - это Chrome Developers Tools:


Если говорить об отладчике, можно воспользоваться Fiddler:


Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

Прочитать объект jqXHR можно с помощью метода jqXHR.getResponseHeader().

Если хотите обработать статус запроса, то это можно сделать так:

5 последних уроков рубрики "Разное"

Как выбрать хороший хостинг для своего сайта?

Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг - это будущее Ваших сайтов

Разработка веб-сайтов с помощью онлайн платформы Wrike

Создание вебсайта - процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.

20 ресурсов для прототипирования

Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

Протокол – документ, в котором зафиксирован ход обсуждения вопросов и принятия решений на заседаниях, совещаниях, собраниях, конференциях. Поэтому, с одной стороны, протокол может быть информационным документом (содержащим информацию о ходе обсуждения управленческих вопросов), с другой – это распорядительный документ, т.к. содержит постановляющую часть.

Протокол документирует деятельность постоянно действующих коллегиальных органов, таких как президиум, профсоюзный комитет. Обязательно протокол ведётся на собраниях, конференциях, семинарах, совещаниях.

Ответственность за подготовку протокола и за правильность записей в протоколе несёт секретарь. Протокол должен быть оформлен не позднее 5 дней со дня заседания.

Все виды протоколов оформляются на общем бланке, который включает следующие реквизиты: наименование организации, наименование вида документа (протокол), дата и номер протокола, место составления протокола, заголовок к тексту, текст, подписи.

Протокол должен отражать содержание заседания, собрания, отвечать требованиям полноты и достоверности информации.

Нумерация протоколов собраний, заседаний профсоюзного комитета ведётся в пределах календарного года.

Заголовок к тексту протокола – это название протоколируемого мероприятия (совещание, заседание, собрание) и наименование коллегиального органа, работа которого протоколируется.

Текст протокола состоит из двух частей: вводной и основной.

Вводная часть текста протокола должна включать следующие вопросы:

  • кто руководит проведением протоколируемого мероприятия;
  • кто вёл протокол;
  • кто присутствовал на совещании (заседании, собрании);
  • кто был приглашён (при необходимости) на совещание, заседание, собрание;
  • какие вопросы обсуждались на совещании, заседании, собрании.

Информация о председателе, секретаре, присутствующих и приглашённых включает фамилии и инициалы должностных лиц. Дополнительно для лиц, приглашённых на совещание, указывается занимаемая должность.

к протоколу конференции

трудового коллектива КГПУ

присутствующих на собрании трудового коллектива КГПУ

Секретарь личная подпись И.О. Фамилия

1. О выполнении коллективного договора за 2013 год. Доклад ректора Н.И. Петрова

Основная часть текста протокола излагается в соответствии с вопросами повестки дня. Построение каждого вопроса осуществляется по схеме: Слушали – выступили – постановили (решили). Эти слова печатают прописными буквами.

Принимаемые решения коллегиального органа (профкома, президиума) требуют голосования. В этом случае после раздела Постановили указывается:

ГОЛОСОВАЛИ: за — …против — …воздержались

Например: форма полного протокола

forma-dogovora

Постановление (решение) указывается в протоколе полностью. Протокол подписывается председателем и секретарём. К протоколу подшиваются представленные на рассмотрение материалы: справки, доклады, проекты и т.д.

Решения, принятые на заседании, доводятся до членов профсоюзной организации в виде копии самого протокола или выписки, постановляющей части из него, либо в виде других распорядительных документов: приказов, решений, составленных на основании протокола.

Протоколы относятся к числу важных документов профсоюзной организации, поэтому хранятся не менее 10 лет и передаются на архивное хранение.

По объёму фиксированных данных, в зависимости от вида заседания и статуса коллегиального органа выбирается форма протокола:

  1. Краткая, в тексте которых указывается лишь постановление.
  2. Сокращённая, в тексте которых печатают фамилии выступающих в порядке их выступления. Название каждого доклада заканчивается решением или постановлением.
  3. Полная, в тексте которых кроме постановлений, кратко записывают выступления докладчиков и других участников собрания, совещания, заседания.
  4. Стенографическая, форма протокола составляется на основе стенографического отчёта: о заседании (стенограммы) и дословно передаёт процесс обсуждения каждого вопроса и выработку решения по нему.

Полные и стенографические протоколы составляют на основе рукописных стенографических или магнитофонных записей, которые ведутся во время заседания.

Например: форма краткого протокола

kratkiy-protokol

Пример краткого протокола

Красноярская краевая организация

Профсоюзная организация КГПУ им. В.П. Астафьева

660049 г. Красноярск тел. (3912) 23-23-16

ПРОТОКОЛ

заседания президиума профсоюзного комитета

28 октября 2013 №14

Председатель: Белова Е.Н.

Секретарь: Моисеева В.Н.

Присутствовали члены президиума из 11 человек – 9 человек, в том числе: Смирнова Ю.Н., Иванова Е.В., Арнольд Е.В., Моисеева В.Н., Дзяугис С.В., Ценюга И.Н., Багдасарьян И.С., Коваленко Т.Д.

Повестка дня:

1.Об итогах участия во Всероссийской акции протеста 15 октября 2013 года профсоюзной организации КГПУ

Постановили:

1.1 Информацию об участии во Всероссийской акции протеста 15 октября 2013 года принять к сведению.

1.2 Выразить благодарность первичным профсоюзным организациям, принявшим активное участие во Всероссийской акции работников образования.

Голосование: единогласно

2.Об информационной работе в профсоюзной организации.

Доклад председателя организационно-массовой комиссии профкома Моисеевой В.Н.

Постановили:

2.1 Принять к сведению информацию об информационной работе в профорганизации.

ответственная Моисеева В.Н.

2.3. Оформить стенд профсоюзной информации в учебном корпусе № 4 и № 5

ответственная Багдасарьян И.С. до 01.12.2013

Голосование: единогласно

Председатель Белова Е.Н. Белова

Пример сокращённого протокола

Красноярская краевая организация

Профсоюзная организация КГПУ им. В.П. Астафьева

660049 г. Красноярск тел. (3912) 23-23-16

ПРОТОКОЛ

заседания президиума профсоюзного комитета

28 октября 2013 г. № 14

Председатель: Белова Е.Н.

Секретарь: Моисеева В.Н.

Присутствовали члены президиума из 11 человек – 9 человек, в том числе: Смирнова Ю.Н., Иванова Е.В., Арнольд Е.В., Моисеева В.Н., Дзяугис С.В., Ценюга И.Н., Багдасарьян И.С., Коваленко Т.Д.

Повестка дня:

1.Об итогах участия во Всероссийской акции протеста 15 октября 2013 года профсоюзной организации КГПУ

Постановили:

1.1 Принять к сведению информацию об участии во Всероссийской акции протеста 15 октября 2013 года.

1.2 Выразить благодарность первичным профсоюзным организациям, принявшим активное участие во Всероссийской акции работников образования.

Голосование: единогласно

2.Об информационной работе в профсоюзной организации.

Доклад председателя организационно-массовой комиссии профкома Моисеевой В.Н.

Постановили:

2.1 Принять к сведению информацию об информационной работе в профорганизации.

ответственная Моисеева В.Н.

2.3. Оформить стенд профсоюзной информации в учебном корпусе № 4 и № 5

ответственная Багдасарьян И.С. до 01.12.2013

Голосование: единогласно

Председатель Белова Е.Н. Белова

Секретарь Моисеева В.Н. Моисеева

Красноярская краевая организация

Профсоюзная организация КГПУ им. В.П. Астафьева

660049 г. Красноярск тел. (3912) 23-23-16

ВЫПИСКА из ПРОТОКОЛА

заседания президиума профсоюзного комитета

28 октября 2013 г. № 14

Председатель: Белова Е.Н.

Секретарь: Моисеева В.Н.

Присутствовали члены президиума из 11 человек – 9 человек, в том числе: Смирнова Ю.Н., Иванова Е.В., Арнольд Е.В., Моисеева В.Н., Дзяугис С.В., Ценюга И.Н., Багдасарьян И.С., Коваленко Т.Д.

Повестка дня:

2.Об информационной работе в профсоюзной организации.

2.Слушали: Моисееву в.н.

Выступили: Арнольд Е.В., Белова Е.Н.

Постановили:

2.1 Принять к сведению информацию об информационной работе профорганизации.

ответственная Моисеева В.Н.

2.3. Оформить стенд профсоюзной информации в учебном корпусе № 4 и № 5

ответственная Багдасарьян И.С. до 01.12.2013

Голосование: единогласно

Председатель Белова Е.Н. Белова

Секретарь Моисеева В.Н. Моисеева

Если информация оказалось полезной, оставляем комментарии, делимся ссылкой на эту статью в своих социальных сетях. Спасибо!

Заголовки отправляемые сервером

header("http заголовок"[, replace]);

Необязательный параметр replace может принимать значения (true или false) и указывает на то, должен ли быть заменен предыдущий заголовок подобного типа, либо добавить данный заголовок к уже существующему.

В отношении функции header() часто применяется функция headers_sent(), которая в качестве результата возвращает true в случае успешной отправки заголовка и false в обратном случае.

Cache-control

Заголовок управления кешированием страниц. Вообще, данная функция является одной из самых распространенных в использовании заголовков.

    Данный заголовок может быть использован со следующими значениями:
  • no-cache - Запрет кеширования. Используется в часто обновляемых страницах и страницах с динамическим содержанием. Его действие подобно meta тегу "pragma: no-cache".
  • public - Разрешение кеширования страницы как локальным клиентом, так и прокси-сервером.
  • private - Разрешение кеширования только локальным клиентом.
  • max-age - Разрешение использования кешированного документа в течение заданного времени в секундах.
  • no-store - Cтраница содержит приватные данные, сохранять в кэше нельзя!

Совсем жесткий запрет кеширования на всех этапах:

Expires

Устанавливает дату и время, после которого документ считается устаревшим. Дата должна указываться в следующем формате (на английском языке):

День недели (сокр.) число (2 цифры) Месяц (сокр.) год часы:минуты:секунды gmt

Например, fri, 09 jan 2002 12:00:00 gmt

Текущее время в этом формате возвращает функция gmdate() в следующем виде:

Last-modified

Указывает дату последнего изменения документа. Дата должна задаваться в том же формате, что и в случае с заголовком expires. Данный заголовок можно не использовать для динамических страниц, так как многие серверы (например, apache) для таких страниц сами выставляют дату модификации.

При запросе это значение передаётся клиентом в специальном заголовке запроса: If-Modified-Since. Обработчик запроса может проверить, изменился ли объект, и если нет - вернуть ответ с пустым телом и кодом ответа 304 Not Modified. Само содержимое страницы не передаётся, и клиент будет использовать то содержимое, которое хранится у него в кэше.

Возможно сделать страницу всегда обновленной:

Позднее, если браузер хочет определить актуальность компонента, он передает заголовок If-None-Match для передачи ETag'а обратно на сервер. Если ETag'и совпадают, ответ от сервера приходит со статус-кодом 304, уменьшая таким образом объем передачи на 12195 байт:

Включить ETag для Apache можно, например, следующей директивой:

Открючить ETag для Apache:

Location

Полезный заголовок, который перенаправляет броузер на указанный адрес. Его действие сравнимо с meta тегом refresh:

Например, этот заголовок может быть использован так:

Content-type

Content-length

Status

Content-Encoding

Content-Encoding : gzip Способность принимать сжатое содержимое клиент отправляет серверу с помощью заголовка Accept-Encoding: gzip. Обычно сервер указывает Accept-Encoding: gzip,deflate.

Range

Разрешить кросс-доменные запросы

X-XSS-Protection

Атака XSS (межсайтовый скриптинг) это тип атаки, при котором вредоносный код может быть внедрён в атакуемую страницу.

Например вот так:

И заголовок X-XSS-Protection управляет этим поведением браузера.

Буду использовать Google Chrome 55.

Без заголовка

Ничего не произойдёт, браузер успешно заблокирует атаку. Chrome, по умолчанию, блокирует угрозу и сообщает об этом в консоли.

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block

В этом случае атака будет предотвращена путём блокирования загрузки страницы.

X-Frame-Options

При помощи данного заголовка можно защититься от так называемого Кликджекинга [Clickjacking].

Представьте, что у злоумышленника есть канал на YouTube и ему хочется больше подписчиков.

Сперва нужно установить расширение для игнорирования данного заголовка.

Создадим простую страницу.


Как можно заметить, я разместил фрейм с подпиской прям над кнопкой (z-index: 1) и поэтому если попытаться на неё нажать, то на самом деле нажмётся фрейм. В этом примере фрейм не полностью прозрачен, но это исправляется значением opacity: 0.

На практике, такое не сработает, потому что у YouTube задан нужный заголовок, но смысл угрозы, надеюсь, понятен.

Для предотвращения страницы быть использованной во фрейме нужно использовать заголовок X-Frame-Options.

  • deny не загружать страницу вообще.
  • sameorigin не загружать, если источник не совпадает.
  • allow-from: ДОМЕН можно указать домен, с которого страница может быть загружена во фрейме.
Без заголовка

Все смогут встроить наш сайт по адресу localhost:1234 во фрейм.

X-Frame-Options: deny
X-Frame-Options: sameorigin

Только страницы с одинаковым источником смогут встраивать во фрейм. Источники совпадают, если домен, порт и протокол одинаковые.

X-Frame-Options: allow-from localhost:4321

Похоже, что Chrome игнорирует такую опцию, т.к. существует заголовок Content-Security-Policy (о ней будет рассказано ниже). Не работает это и в Microsoft Edge.

X-Content-Type-Options

Данный заголовок предотвращает атаки с подменой типов MIME (`) >) app.listen(1234)

Без заголовка

Хоть script.txt и является текстовым файлом с типом text/plain, он будет запущен как скрипт.

X-Content-Type-Options: nosniff

На этот раз типы не совпадают и файл не будет исполнен.

Content-Security-Policy

Это относительно молодой заголовок и помогает уменьшить риски атаки XSS в современных браузерах путём указания в заголовке какие именно ресурсы могут подргружаться на странице.

Например, можно попросить браузер не исполнять inline-скрпиты и загружать файлы только с одного домена. Inline-скрпиты могут выглядеть не только как , но и как

Посмотрим как это работает.

Без заголовка

Это работает так, как вы и ожидали

Content-Security-Policy: default-src 'none'

default-src применяет правило для всех ресурсов (картинки, скрипты, фреймы и т.д.), значение 'none' блокирует всё. Ниже продемонстрировано что происходит и ошибки, показываемые в браузере.

Chrome отказался запускать любые скрипты. В таком случае не получится даже загрузить favicon.ico.

Content-Security-Policy: default-src 'self'

Теперь можно использовать ресурсы с одного источника, но по прежнему нельзя запускать внешние и inline-скрипты.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

На этот раз мы разрешили исполнение и inline-скриптов. Обратите внимание, что XSS атака в запросе тоже была заблокирована. Но этого не произойдёт, если одновременно поставить и unsafe-inline, и X-XSS-Protection: 0.

Другие значения

Я этого не проверял, но я думаю, что следующие заголовки эквиваленты:

  • frame-ancestors 'none' и X-Frame-Options: deny
  • frame-ancestors 'self' и X-Frame-Options: sameorigin
  • frame-ancestors localhost:4321 и X-Frame-Options: allow-from localhost:4321
  • script-src 'self' без 'unsafe-inline' и X-XSS-Protection: 1

Strict-Transport-Security

После этого мы будем перенаправлены на защищённую версию Facebook.

Если пользователь был залогинен в Facebook дома, а потом попытался открыть его из небезопасной точки доступа, то ему ничего не угрожает, т.к. браузеры запоминают этот заголовок.

Но что будет, если подключиться в небезопасной сети первый раз? В этом случае защититься не получится.

  • max-age=15552000 время, в секундах, которое браузер должен помнить о заголовке.
  • includeSubDomains Если указать это опциональное значение, то заголовок распространяется и на все поддомены.
  • preload если владелец сайта хочет, чтобы домен попал в предопределённый список, поддерживаемый Chrome (и используемый Firefox и Safari).

Public-Key-Pins

Так делает Facebook:

Зачем это нужно? Не достаточно ли доверенных центров сертификации (CA)?

Попробуем создать сертификат для facebook.

И сделать его доверенным в локальной системе.

А теперь запустим веб сервер, использующий этот сертификат.

Переключимся на сервер

Посмотрим что получилось

Отлично. curl подтверждает сертификат.

Так как я уже заходил на Facebook и Google Chrome видел его заголовки, то он должен сообщить об атаке но разрешить страницу, так?

Неа. Ключи не проверялись из-за локального корневого сертификата [Public-key pinning bypassed]. Это интересно…

Тот же результат. Думаю это фича.

Но в любом случае, если не добавлять эти сертификаты в локальное хранилище, открыть сайты не получится, потому что опции продолжить небезопасное соединение в Chrome или добавить исключение в Firefox не будет.

Content-Encoding: br

Данные сжаты при помощи Brotli.

Алгоритм обещает лучшее сжатие чем gzip и сравнимую скорость разархивирования. Поддерживается Google Chrome.

Разумеется, для него есть модуль в node.js.

Исходный размер: 700 Кб
Brotli: 204 Кб
Gzip: 241 Кб

Timing-Allow-Origin

С помощью Resource Timing API можно узнать сколько времени заняла обработка ресурсов на странице.

Поскольку информация о времени загрузки может быть использована чтобы определить посещал ли пользователь страницу до этого (обращая внимание на то, что ресурсы могут кэшироваться), стандарт считается уязвимым, если давать такую информацию любым хостам.

Похоже, если не указать Timing-Allow-Origin, то получить детальную информацию о времени операций (поиска домена, например) можно только для ресурсов с одним источником.

Использовать можно так:

Alt-Svc

Альтернативные Сервисы [Alternative Services] позволяют ресурсам находиться в различных частях сети и доступ к ним можно получить с помощью разных конфигураций протокола.

Такой используется в Google:

Ниже несколько P3P заголовков, которые я встречал:

Организация, основавшая P3P, Консорциум Всемирной паутины (W3C), приостановила работу над протоколом несколько лет назад из-за того, что современные браузеры не до конца поддерживают протокол. В результате, P3P устарел и не включает в себя технологии, которые сейчас используются в сети, поэтому большинство сайтов не поддерживают P3P.

Читайте также: