Экзотичные заголовки HTTP. Правильные HTTP заголовки. Готовим почву для SEO на этапе разработки
Описание конкретных заголовков смотрите в статье Список заголовков HTTP .
Заголовки HTTP (англ. HTTP Headers ) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.
Все заголовки разделяются на четыре основных группы:
Название параметра должно состоять минимум из одного печатного символа (ASCII -коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.
Значение может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).
Предусматривается размещение значения на нескольких строках (перенос строки). Для указания переноса в начале следующей строки должен находиться хотя бы один пробельный символ.
Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовков должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.
Пример с многострочными значениями и одинаковыми именами заголовков (обратите внимание на регистр символов и пробелы):
Content-type: text/html; charset=windows-1251 Allow: GET, HEAD Content-Length: 356 ALLOW: GET, OPTIONS Content-Length: 1984
Правильный компактный вариант преобразования и интерпретации:
Content-Type: text/html;charset=windows-1251 Allow: GET,HEAD,OPTIONS Content-Length: 1984
В этом случае не допустимо принимать значение Content-Length равное 356. При объединении значений Allow чтобы не потерять семантический смысл была добавлена запятая в конец первого поля и убран бессмысленно дублирующийся элемент «GET».
Применяемые в заголовках структуры Дата и времяТолько дата указывается в заголовках Date , Expires , Last-Modified , If-Modified-Since , If-Unmodified-Since . Дата может присутствовать в заголовках If-Range и Warning .
В HTTP исторически используется три формата:
- Fri, 04 Jul 2008 08:42:36 GMT - RFC 822 .
- Friday, 04-Jul-08 08:42:36 GMT - RFC 850 .
- Fri Jul 4 08:42:36 2008 - результат функции asctime() языка ANSI C .
Сейчас рекомендуется использовать только первый формат по RFC 822 , но для совместимости клиентам и серверам лучше поддерживать и другие.
Время всегда указывается для часового пояса GMT (UTC+0). Год записывается четырьмя цифрами. День, час, минута и секунда дополняются нулями до двух символов. Для месяца и названия недели применяются трёхбуквенные стандартные сокращения на английском языке.
Дни недели начиная с понедельника: Mon , Tue , Wed , Thu , Fri , Sat , Sun .
Месяцы с января по декабрь: Jan , Feb , Mar , Apr , May , Jun , Jul , Aug , Sep , Oct , Nov , Dec .
В PHP для преобразования местного времени во время по Гринвичу используется функция gmdate(). Примеры формирования дат для заголовков HTTP:
// Текущая дата формирования документа: header ("Date: " . gmdate ("D, d M Y H:i:s" , time () ) . " GMT" ) ; // Дата модификации указанного файла: $fp = "data/my-foo.txt" ; // путь к файлу header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" , filemtime ($fp ) ) . " GMT" ) ; // Документ предположительно изменится через час: header ("Expires: " . gmdate ("D, d M Y H:i:s" , time () + 3600 ) . " GMT" ) ; // 3600 - количество секунд относительно текущего момента.
Байтовые диапазоныПри работе с фрагментами содержимого в специальных заголовках используются байтовые диапазоны (англ. byte ranges ). В них можно указать как один фрагмент, так и несколько разделяя их запятыми « , ». Диапазоны применяются в заголовках Range и Content-Range . В заголовке Accept-Ranges перечисляются только единицы измерения.
В байтовых диапазонах обязательно в начале указываются название единиц измерения за которым следует символ « = ». В настоящий момент кроме единиц bytes никакие другие не применяются. За символом « = » располагаются сами диапазоны. Каждый из них является разделённой дефисом « - » парой натуральных чисел или нуля. Первый элемент указывает начальный байт, а второй - конечный. Нумерация в диапазонах начинается с нуля.
Начальный или конечный байт может быть не указан. При отсутствии последнего байта считается что речь идёт о фрагменте от начального байта до конца содержимого. Если отсутствует начало, то номер конечного байта воспринимается как количество запрашиваемых байт от конца содержимого.
Если первый байт больше чем последний, то диапазон считается синтаксически недействительным (англ. syntactically invalid ). Поля заголовка, содержащие диапазоны с синтаксически недействительными значениями, игнорируются. Если первый байт выходит за пределы объёма ресурса, то диапазон игнорируется. Если последний байт выходит за пределы содержимого, то диапазон обрезается до конца.
URL:User-Agent:
Показать html-код страницы
Кодировка:
Автоопределение
UTF-8
ISO-8859-1
Windows-1251
KOI8-R
Код состояния HTTP (англ. HTTP status code ) - код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Пример:
403 Access allowed only for registered users
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния:
- 1xx: Informational (русск. Информационный ) - запрос получен и понят, а обработка продолжается.
- 2xx: Success (русск. Успешно ) - запрос был успешно получен, понят и обработан.
- 3xx: Redirection (русск. Перенаправление ) - для выполнения запроса должны быть предприняты дальнейшие действия.
- 4xx: Client Error (русск. Ошибка клиента ) - запрос имеет плохой синтаксис или не может быть выполнен.
- 5xx: Server Error (русск. Ошибка сервера ) - сервер не в состоянии выполнить допустимый запрос.
Ниже, представлены коды ответа из реестра кодов состояния IANA.
1xx: Informational
В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
100 Continue
(русск. Продолжать
)
Сервер удовлетворён начальными сведениями о запросе. Клиент может продолжать пересылать заголовки.
101 Switching Protocols
(русск. Переключение протоколов
)
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.
102 Processing
(русск. Идёт обработка
)
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.
2xx: Success
Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
200 OK
(русск. Хорошо
)
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.
201 Created
(русск. Создано
)
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.
202 Accepted
(русск. Принято
)
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.
203 Non-Authoritative Information
(русск. Неавторитетная информация
)
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.
204 No Content
(русск. Нет содержимого
)
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.
205 Reset Content
(русск. Сбросить содержимое
)
Сервер обязывает клиента спросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.
206 Partial Content
(русск. Частичное содержимое
)
Сервер удачно выполнил запрос клиента, но передал только часть документа. Такой ответ сервер может отправить если в заголовке запроса клиента есть поле Content-Range. Особое внимание при работе с подобными ответами следует уделить кэшированию.
207 Multi-Status
(русск. Многостатусный
)
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.
226 IM Used
(русск. IM использовано
)
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.
3xx: Redirection
Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).
Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.
300 Multiple Choices
(русск. Несколько выборов
)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.
301 Moved Permanently
(русск. Перемещёно окончательно
)
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.
302 Found
(русск. Найдено
)
Запрошенный документ был временно перенесен на другой URI, указанный в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.
303 See Other
(русск. Смотреть другое
)
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.
304 Not Modified
(русск. Не изменено
)
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.
305 Use Proxy
(русск. Использовать прокси
)
Запрос к запрашиваемому ресурсе должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).
306 (Reserved)
(русск. Зарезервировано
)
Использовалось раньше. В настоящий момент зарезервировано.
307 Temporary Redirect
(русск. Временное перенаправление
)
Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.
4xx: Client Error
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
400 Bad Request
(русск. Плохой запрос
)
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.
401 Unauthorized
(русск. Неавторизован
)
Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.
402 Payment Required
(русск. Необходима оплата (зарезервировано)
)
Предполагается использовать в будущем. В настоящий момент не используется.
403 Forbidden
(русск. Запрещено
)
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.
404 Not Found
(русск. Не найдено
)
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.
405 Method Not Allowed
(русск. Метод не поддерживается
)
Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.
406 Not Acceptable
(русск. Не приемлемо
)
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.
407 Proxy Authentication Required
(русск. Необходима авторизация прокси
)
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.
408 Request Timeout
(русск. Время ожидания истекло
)
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.
409 Conflict
(русск. Конфликт
)
Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.
410 Gone
(русск. Удалён
)
Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.
411 Length Required
(русск. Необходима длина
)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.
412 Precondition Failed
(русск. Условие «ложно»
)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.
413 Request Entity Too Large
(русск. Запрашиваемые данные слишком большие
)
Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.
414 Request-URI Too Long
(русск. Запрашиваемый URI слишком длинный
)
Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.
415 Unsupported Media Type
(русск. Неподдерживаемый тип данных
)
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.
416 Requested Range Not Satisfiable
(русск. Запрашиваемый диапазон не достижим
)
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.
417 Expectation Failed
(русск. Ожидаемое ошибочно
)
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.
422 Unprocessable Entity
(русск. Необрабатываемый экзмепляр
)
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.
423 Locked
(русск. Заблокировано
)
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.
424 Failed Dependency
(русск. Невыполненная зависимость
)
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.
426 Upgrade Required
(русск. Необходимо обновление
)
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.
5xx: Server Error
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
500 Internal Server Error
(русск. Внутренняя ошибка сервера
)
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.
501 Not Implemented
(русск. Не выполнимо
)
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.
502 Bad Gateway
(русск. Плохой шлюз
)
Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.
503 Service Unavailable
(русск. Сервис недоступен
)
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.
504 Gateway Timeout
(русск. Шлюз не отвечает
)
Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.
505 HTTP Version Not Supported
(русск. Версия HTTP не поддерживается
)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.
506 Variant Also Negotiates (Experimental)
(русск. Вариант тоже согласован (экспериметальное)
)
В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.
507 Insufficient Storage
(русск. Закончилось место
)
Не хватает места для выполнения текущего запроса. Проблема может быть временной.
510 Not Extended
(русск. Не расширено
)
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.
С помощью заголовков http происходит обмен служебными сведениями между клиентом и сервером. Эта информация остается невидимой для пользователей, но без нее невозможна правильная работа браузера. Для обычных пользователей сведения об этом и о задачах http заголовков покажутся довольно сложными, но на самом деле они не содержат трудных формулировок. Это то, с чем сталкивается веб-пользователь ежедневно.
заголовки?«Протокол передачи гипертекста» - именно так переводится http заголовок. Благодаря его существованию, возможна связь «клиент-сервер». Если объяснить простыми словами, пользователь браузера посылает запрос, инициируя соединение с сервером. Последний, по умолчанию, ждет запрос от клиента, обрабатывает его и посылает обратно итоговую информацию или ответ. В поисковой строке пользователь «вбивает» адрес сайта, который начинается с http:// и получает результат в виде открывшейся страницы.
Когда печатается адрес сайта в соответствующей строке, браузер находит требующийся сервер с помощью DNS. Сервер распознает http заголовок (один или несколько), который посылает ему клиент, а затем выдает требуемый header. Набор обязательных состоит из уже существующих заголовков и не найденных.
В общем, http заголовки достаточно эффективные. Их не видно в HTML-кодировании, они отправляются перед запрашиваемыми сведениями. Многие заголовки автоматически высылаются сервером. Для того чтобы его отослать на языке PHP, следует воспользоваться функцией header.
Схема взаимодействия браузера и сайта достаточно простая. Так, http заголовок начинает строку запроса, который далее посылается серверу. В ответ приходит нужная клиенту информация. Между прочим, уже семнадцать лет - самый используемый в Интернете. Он простой, надежный, работает быстро и гибко. Главная задача http - запрос сведений с web-сервера. Клиентом является браузер, а сервером - ligthttp, apache, nginx. Если соединение между ними произошло успешно, сервер в ответ на запрос получает нужные сведения. Информация http содержит текстовые, звуковые файлы, видео.
Протокол может быть транспортом для других. Запрос клиента состоит из трех частей:
- стартовой строки (тип сообщения);
- заголовков (параметры сообщения);
- тела информации (сообщение, которое отделяется пустой строчкой).
Стартовая строка - обязательный элемент запроса поля заголовков http. Структура запроса пользователя состоит из трех основных частей:
Современные браузеры используют версию 1.1. Далее следуют заголовки в формате "Имя: значение".
Суть в том, что кэширование обеспечивает хранение HTML-страниц, других файлов в кэше (место в операционной памяти, на жестком диске компьютера). Это нужно для того чтобы ускорить к ним повторный доступ и сэкономить трафик.
Кэш имеет браузер клиента, промежуточный шлюз и прокси-сервер. Перед тем как отправить сообщение по URL, браузер проверит наличие объекта в кэше. Если объекта нет, запрос передается следующему серверу, где проверяется кэширование http заголовков на сервере nginx. Шлюзы и прокси используются разными пользователями, поэтому кэш является разделяемым.
HTTP-кэширование способно не только существенно ускорить работу сайта, но и предоставить старую версию страницы. С помощью происходит отправка заголовков на отклик. При этом не может быть кэширована информация, запрошенная по протоколу HTTPS.
Одними из самых главных механизмов кеша считаются http заголовки expires. Эти заголовки сообщают о сроке годности предоставленной в отклике информации. В них указывается время и дата, когда кэш будет считаться устаревшим. Например, такой заголовок выглядит следующим образом: Expires: Wen, 30 Nov 2016 13:45:00 GMT. Данная структура используется почти везде, в том числе для кэширования страниц и картинок. Если пользователь выберет старую дату, сведения не будут кэшироваться.
Заголовки http proxy относятся к категории header link. Они не кэшируются по умолчанию. Чтобы кэш работал правильно, каждый URL должен соответствовать одному варианту содержимого. Если страница действует на двух языках, каждая версия должна иметь собственный URL. Заголовок vary сообщает кэшу названия заголовков запроса. К примеру, если отображение запроса зависит от браузера, серверу необходимо также отправлять заголовок. Таким образом, в кэше сохраняются разные варианты запросов и типы документов. TTP заголовок accept необходим для того чтобы составлять списки допустимых форматов используемого ресурса, с ним достаточно легко работать, так как он отсеивает ненужные.
Всего существует четыре группы заголовков, которые передают служебную информацию. Это основные заголовки - они содержатся в любом сообщении сервера и клиента, запроса и ответа, а также сущности. Последние описывают содержание любого сообщения от клиента и сервера.
HTTP заголовок authorization считается дополнительным. Когда web-страница спрашивает у клиента авторизацию, браузер отображает специальное окно с полями для ввода логина и пароля. После того как пользователь введет свои данные, браузер передает запрос http. Он содержит заголовок «авторизация».
Чтобы увидеть http заголовок, необходимо установить плагины для браузера, например, firefox:
- Firebug. Просмотреть заголовки можно во вкладке net (сеть), где выбрать all (все). Этот плагин обладает функциями, которые будут полезны веб-разработчику.
- Live http headers. Простой плагин, предназначенный для просмотров http заголовков. С его помощью вручную можно сгенерировать запрос.
- Пользователи Ghrome легко увидят заголовки, если нажмут кнопку настроек, выберут инструменты разработчика (net works).
Когда плагины будут установлены, запустите их и браузера.
Методы запросовМетоды, которые используются в HTTP, имеют сходства с инструкциями, которые передаются в виде сообщения серверу. Это специальное слово на английском языке.
- Метод GET. Его используют для запроса информации с ресурса. Именно с него начинаются все действия.
- POST. С его помощью происходит отправка данных. Например, сообщение в социальной сети или комментарий, браузер помещает в тело POST-запроса и отправляет серверу.
- HEAD. Метод имеет сходства с первым, но выполняет легкую функцию. Он запрашивает только мета-данные, исключая из ответа сообщение. Методом пользуются, если хотят получить информацию о файлах без скачивания. Его используют, если хотят проверить работоспособность ссылок на сервере.
- PUT. Загружает данные на URL. Передает большие объемы данных.
- OPTIONS. Работает с конфигурациями сервера.
- URI. Идентифицирует ресурс и содержит в себе URL.
Сервер отвечает на запросы клиента длинными сообщениями. Ответ состоит из нескольких строк, в которых указывается версия протокола, код статуса сервера (200). Он говорит о том, что изменилось на сервере за время обработки поступившего запроса:
URL - это сердце веб-общения между клиентом и сервером. Запрос обычно отправляется через URL - единый указатель ресурсов. Структура запроса url очень проста. Она состоит из нескольких элементов: протокол http (заголовок), hoot (адрес сайта), port, resourte path и query.
Протокол доступен также для безопасного соединения https и обмена информацией. URL-адрес содержит информацию о размещении конкретного сайта в Интернете. Адрес включает в себя имя домена, путь к странице, а также ее название.
Основной недостаток работы с URL - это неудобное взаимодействие с латинским алфавитом, а также цифрами и символами. В SEO оптимизации играет не последнюю роль.
Активным пользователям компьютеров и разработчикам не помещает ознакомиться с некоторыми профессиональными рекомендациями, которые дают специалисты в этой области:
- Обозначайте сроки годности файлов и документов, с учетом обновлений. Статистическая информация указывается в больших значениях max-age.
- Отдельный документ должен быть доступен лишь по одному URL.
- Если обновляете файл, который будет скачиваться пользователем, измените его имя и ссылку на него. Это гарантирует скачивание нового, а не устаревшего документа.
- Заголовки Last-Modified должны соответствовать настоящей дате последних изменений содержания. Не следует пересохранять страницы и документы, если не будете их менять.
- Используйте POST-запросы лишь там, где это нужно. Сведите к минимуму работу с SSL.
- Заголовки перед отправкой сервером следует проверять плагином REDbot.
- Перевод
Привет Хабрахабр! В этой статье будут наглядно продемонстрирован результат применения некоторых важных и экзотичных HTTP заголовков, большинство из которых связаны с безопасностью.
X-XSS-Protection Атака XSS (межсайтовый скриптинг) это тип атаки, при котором вредоносный код может быть внедрён в атакуемую страницу.Например вот так:
Hello, alert("hacked")
Такой тип атаки легко обнаружить и браузер вполне может с этим справиться: если в исходном коде содержится часть запроса, то это может оказаться угрозой.
И заголовок X-XSS-Protection управляет этим поведением браузера.
Принимаемые значения:
- 0 фильтр выключен
- 1 фильтр включен. Если атака обнаружена, то браузер удалит вредоносный код.
- 1; mode=block . Фильтр включен, но если атака обнаружится, страница не будет загружена браузером.
- 1; report=http://domain/url . фильтр включен и браузер очистит страницу от вредоносного кода, при этом сообщив о попытке атаки. Тут используется функция Chromium для отправки отчёта о нарушении политика защиты контента (CSP) на определённый адрес.
Var express = require("express")
var app = express()
app.use((req, res) => {
if (req.query.xss) res.setHeader("X-XSS-Protection", req.query.xss)
res.send(`Hello, ${req.query.user || "anonymous"}`)
})
app.listen(1234)
Буду использовать Google Chrome 55.
Ничего не произойдёт, браузер успешно заблокирует атаку. Chrome, по умолчанию, блокирует угрозу и сообщает об этом в консоли.
Он даже выделяет проблемный участок в исходном коде.
О нет!
Страница была очищена из-за явного указания заголовка.
В этом случае атака будет предотвращена путём блокирования загрузки страницы.
Атака предотвращена и сообщение об этом отправлено по соответствующему адресу.
Представьте, что у злоумышленника есть канал на YouTube и ему хочется больше подписчиков.
Он может создать страницу с кнопкой «Не нажимать», что будет значить, что все на неё обязательно нажмут. Но поверх кнопки находится абсолютно прозрачный iframe и в этом фрейме прячется страница канала с кнопкой подписки. Поэтому при нажатии на кнопку, на самом деле пользователь подписывается на канал, если конечно, он был залогинен в YouTube.
Продемонстрируем это.
Echo -e "US\nCA\nSF\nGoogle\nXX\nwww.google.com\[email protected]" | \
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /etc/certs/google.key \
-out /etc/certs/google.crt
sudo cp /etc/certs/*.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
certutil -A -t "C," -n "Google" -d sql:$HOME/.pki/nssdb -i /etc/certs/google.crt
echo 127.0.0.1 www.google.com | sudo tee -a /etc/hosts
sudo node server.js google
Тот же результат. Думаю это фича.
Но в любом случае, если не добавлять эти сертификаты в локальное хранилище, открыть сайты не получится, потому что опции продолжить небезопасное соединение в Chrome или добавить исключение в Firefox не будет.
Алгоритм обещает лучшее сжатие чем gzip и сравнимую скорость разархивирования. Поддерживается Google Chrome .
Разумеется, для него есть модуль в node.js.
Var shrinkRay = require("shrink-ray")
var request = require("request")
var express = require("express")
request("https://www.gutenberg.org/files/1342/1342-0.txt", (err, res, text) => {
if (err) throw new Error(err)
var app = express()
app.use(shrinkRay())
app.use((req, res) => res.header("content-type", "text/plain").send(text))
app.listen(1234)
})
Исходный размер: 700 Кб
Brotli: 204 Кб
Gzip: 241 Кб
Поскольку информация о времени загрузки может быть использована чтобы определить посещал ли пользователь страницу до этого (обращая внимание на то, что ресурсы могут кэшироваться), стандарт считается уязвимым, если давать такую информацию любым хостам.
setTimeout(function() {
console.log(window.performance.getEntriesByType("resource"))
}, 1000)
Похоже, если не указать Timing-Allow-Origin
, то получить детальную информацию о времени операций (поиска домена, например) можно только для ресурсов с одним источником.
Использовать можно так:
- Timing-Allow-Origin: *
- Timing-Allow-Origin: http://foo.com http://bar.com
Такой используется в Google:
Некоторые браузеры требуют, чтобы cookies третьих лиц поддерживали протокол P3P для обозначения мер конфиденциальности.
Организация, основавшая P3P, Консорциум Всемирной паутины (W3C), приостановила работу над протоколом несколько лет назад из-за того, что современные браузеры не до конца поддерживают протокол. В результате, P3P устарел и не включает в себя технологии, которые сейчас используются в сети, поэтому большинство сайтов не поддерживают P3P.
Я не стал слишком углубляться, но видимо заголовок нужен для IE8 чтобы принимать cookies третьих лиц.
Например, если в IE настройка приватности высокая, то все cookies с сайтов, у которых нет компактной политики конфиденциальности, будут блокированы, но те у которых есть заголовки похожие на вышеупомянутые, заблокированы не будут.
Какие из перечисленных HTTP заголовков Вы используете в проектах?
Привет, читатель блога сайт! Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе . В данной публикации вы найдете все поля HTTP заголовков их описание и небольшие примеры. Возможно, в этой рубрике появится более подробные публикации про каждую из групп полей заголовка, пока я советую обратиться вам к официальной документации .
Поля HTTP заголовков запроса пользователяНиже приведены поля HTTP заголовка запроса пользователя , это те поля, которые могут быть использованы в . Обратите внимание на то, что в данной таблицы сведены поля HTTP заголовков при запросе и служебные поля HTTP заголовков запроса. Так же для удобства в справочнике поля заголовков HTTP запроса упорядочены в алфавитном порядке. В таблице будут приведены сначала служебные поля заголовка запроса, а затем поля заголовка объекта.
| Поля HTTP заголовка | Описание поля HTTP заголовка | Пример |
| Accept | Поле заголовка запроса Accept используется, чтобы определить тип информации, который должен содержаться в ответе | Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c |
| Accept-Charset | Поле заголовка запроса Accept-Charset указывает на , которая должна быть в ответе сервера. Другими словами: данное поле указывает на то, какие наборы символов приемлемы для ответов сервера | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
| Accept-Encoding | Поле заголовка запроса Accept-Encoding указывает серверу на то, какие способы кодирования приемлемы для ответа. | Accept-Encoding: compress, gzip |
| Accept-Language | Поле заголовка запроса Accept-Language указывает серверу приемлемые языки (естественные языки: русский, китайский, английский и пр.) | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
| Authorization | Поле заголовка запроса Authorization используется для отправки данных авторизации на сервер | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Content-Disposition | Поле заголовка запроса Content-Disposition используется для сохранения файлов на сервере | Content-Disposition: form-data; name="MessageTitle" Content-Disposition: form-data; name="AttachedFile1"; filename="photo-1.jpg" |
| Expect | Поле заголовка запроса Expect позволяет клиенту задать поведение сервера, например, при помощи данного поля клиент может сообщить серверу, что ожидает от него дальнейших действий. | Expect: 100-continue |
| From | Поле заголовка запроса From служит для передачи серверу адреса электронной почты клиента | From: [email protected] |
| Host | Поле заголовка запроса Hostиспользуется для указания доменного имени и порта запрашиваемого ресурса. | Host: сайт |
| If-Match | Поле заголовка запроса If-Match используется клиентом для эффективного обновления кэшируемой информации. В данном поле передается список тегов версий сущности (HTTP объекта) | If-Match: «xyzzy»
If-Match: «xyzzy», «r2d2xxxx», «c3piozzzz» If-Match: * |
| If-Modified-Since | Поле заголовка запроса If-Modified-Since указывает на то, что сервер должен отправить объект, если он изменился с даты, указанной в заголовке. | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| If-None-Match | Поле заголовка запроса If-None-Match выполняется клиентом, у которого есть один или более объектов, ранее полученных из ресурса, может проверить, что ни один из тех объектов не является текущим, включая список их связанных тэгов объекта в поле заголовка If-None-Match | If-None-Match: «xyzzy»
If-None-Match: W/"xyzzy" If-None-Match: «xyzzy», «r2d2xxxx», «c3piozzzz» If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: * |
| If-Range | Поле заголовка запроса If-Range используется клиентом в том случае, когда он имеет частичную копию объекта в его кэше, и желает иметь современную копию всего объекта | If-Range: «737060cd8c284d8af7ad3082f209582d» |
| If-Unmodified-Since | Поле заголовка запроса If-Unmodified-Since используется клиентом если если запрошенный ресурс не был изменен со времени, указанного в этом поле. | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| Max-Words | Поле заголовка запроса Max-Words используется , чтобы ограничить число прокси-серверов, иначе может получиться бесконечный цикл. | Max-Forwards: 10 |
| Proxy-Authorization | Поле заголовка запроса Proxy-Authorization содержит в себе информацию для авторизации на прокси-сервере | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | Поле заголовка запроса Range указывает фрагмента ресурса, который требуется клиенту, чтобы не тянуть весь ресурс целиком | Range: bytes=50000-99999,250000-399999,500000- |
| Referer | Поле заголовка запроса Referer содержит в себе URI ресурса (читай про ), с которого клиент перешел на данный ресурс | Referer: http://сайт |
| TE | Поле заголовка запроса TE содержит список расширенных способов кодирования, поддерживаемых клиентом, для передачи. | TE: deflate
TE: trailers, deflate;q=0.5 |
| User-Agent | Поле заголовка запроса User-Agent содержит в себе полную информацию о клиенте пользователя, например, о браузере. | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| Content-Encoding | Поле заголовка запроса Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия | Content-Encoding: gzip |
| Content-Language | Поле заголовка запроса Content-Language указывает серверу на каком языке нужна информация (), находящаяся в теле объекта. | Content-Language: mi, en |
| Content-Length | Поле заголовка запроса Content-Length указывает необходимую длину тела сообщения в байтах | Content-Length: 3495 |
| Content-Location | Поле заголовка запроса Content-Location используется для идентификации исходного местоположения объекта на сервере. | «Content-Location» «:» (absoluteURI | relativeURI) |
| Content-MD5 | Поле заголовка запроса Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения. | |
| Content-Range | Поле заголовка запроса Content-Range используется в том случае, когда клиент запрашивает фрагмент . Данное поле имеет значение | |
| Content-Type | Поле заголовка запроса Content-Type используется для указания в теле сообщения. | |
| Content-Version | Поле заголовка запроса Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется) | |
| Derived-From | Поле заголовка запроса Derived-From это аналог Content-Version (обычно не реализуется) | |
| Expires | Поле заголовка запроса Expires содержит того момента, когда информация HTTP объекта перестанет быть актуальной | |
| Last-Modified | Поле заголовка запроса Last-Modified содержит дату последней модификации HTTP объекта | |
| Link | Поле заголовка запроса Link указывает на логически связный с сущностью ресурс (обычно не реализуетсяя) | |
| Title | Поле заголовка запроса Title содержит заголовок объекта |
Ниже в таблицы приведены поля HTTP заголовка ответа сервера . Поля HTTP заголовка ответа сервера – это те поля, которые могут быть использованы в сервера на запросы клиента. Обратите внимание на то, что таблица содержит не только служебные поля заголовка ответа, но и поля заголовка HTTP объекта при ответе сервера.Сначала в таблицы идут служебные поля заголовка HTTP ответа, а затем поля заголовка HTTP объекта при ответе сервера. Справочник полей HTTP заголовка ответов сервера упорядочен в алфавитном порядке.
| Поля HTTP заголовка | Описание поля HTTP заголовка | Пример |
| Accept-Ranges | Поле заголовка ответа Accept-Ranges. Этим полем сервер сообщает клиенту о том, в каких единицах измерения тот может запрашивать фрагменты объекта | Accept-Ranges: bytes Accept-Ranges: none |
| Age | Поле заголовка ответа Age хранит в себе количество секунд с момента последней модификации ресурса | |
| Alternates | Поле заголовка ответа Alternates указывает на альтернативные способы представления ресурса и обычно не реализуется серверами. | |
| Content-Disposition | Поле заголовка ответа Content-Disposition используется для сохранения файлов на | |
| ETag | Поле заголовка ответа ETag идентифицирует | ETag: «56d-9989200-1132c580» |
| Location | Поле заголовка ответа Location указывает URI, на котором хранится запрошенный ресурс | Location:absoluteURI |
| Proxy-Authenticate | Поле заголовка ответа Proxy-Authenticate содержит в себе информацию о параметрах | Proxy-Authenticate:challenge |
| Public | Поле заголовка ответа Public содержит в себе список доступных методов (читай про ) для всего HTTP сервера | Public: OPTIONS, MGET, MHEAD, GET, HEAD |
| Retry-After | Поле заголовка ответа Retry-After обычно используется сервером вместе с кодом состояния 503 () и указывает на то, как долго ресурс будет недоступен | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120 |
| Server | Поле заголовка ответа Server содержит в себе необходимую информацию о сервере для установления | Server: /2.2.17 (Win32) PHP/5.3.5 |
| Vary | Поле заголовка ответа Vary указывает клиенту на то, что HTTP объект имеет несколько источников и его содержимое может изменяться в зависимости от выбранного источника, указанного в URI | Vary: Accept-Language, Accept-Encoding |
| WWW-Authenticate | Поле заголовка ответа WWW-Authenticate используется сервером вместе с 401 (). В данному поле указываются схемы аутентификации и требуемые параметры для доступа к ресурсу | WWW-Authenticate = «WWW-Authenticate» «:» 1#challenge |
| Allow | Поле заголовка ответа Allow передает клиенту методы, которые тот может использовать | Allow: GET, HEAD, PUT |
| Content-Encoding | Поле заголовка ответа Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия | Content-Encoding: gzip |
| Content-Language | Поле заголовка ответа Content-Language указывает клиенту на каком языке информация, находящаяся в теле объекта. | Content-Language: mi, en |
| Content-Length | Поле заголовка ответа Content-Length указывает необходимую длину тела сообщения в байтах | Content-Length: 3495 |
| Content-Location | Поле заголовка ответа Content-Location используется для идентификации исходного местоположения объекта на сервере. | |
| Content-MD5 | Поле заголовка ответа Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения. | Content-MD5: |
| Content-Range | Поле заголовка ответа Content-Range используется в том случае, когда клиент запрашивает фрагмент HTTP сообщение. Данное поле имеет значение байтового диапазона требуемого фрагмента | Content-Range: bytes 88080384-160993791/160993792 |
| Content-Type | Поле заголовка ответа Content-Type используется для указания медиа типа данных в теле сообщения. | Content-Type: text/html;charset=utf-8 |
| Content-Version | Поле заголовка ответа Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется) | |
| Derived-From | Поле заголовка ответа Derived-From это аналог Content-Version (обычно не реализуется) | |
| Expires | Поле заголовка ответа Expires содержит дату и время того момента, когда информация HTTP объекта перестанет быть актуальной | Expires: Tue, 31 Jan 2012 15:02:53 GMT |
| Last-Modified | Поле заголовка ответа Last-Modified содержит дату последней модификации HTTP объекта | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| Link | Поле заголовка ответа Link указывает на логически связный с сущностью ресурс (обычно не реализуетсяя) | |
| Title | Поле заголовка ответа Title содержит заголовок объекта |
Напомню, что общие поля заголовка HTTP сообщения могут быть использованы, как при HTTP запросах, так и при ответах сервера. Ниже вы найдете таблицу с кратким описанием и примерами общих полей HTTP заголовка. Справочник общих полей HTTP заголовка отсортирован по алфавиту.
| Поля HTTP заголовка | Описание поля HTTP заголовка | Пример |
| Cache-Control | Общее поле HTTP заголовка Cache-Control определяет директивы для управления кэшем, которым должны следовать все кэширующие механизмы | Cache-Control: no-cache
Cache-Control: no-store Cache-Control: max-age=3600 Cache-Control: max-stale=0 Cache-Control: min-fresh=0 Cache-Control: no-transform Cache-Control: only-if-cached Cache-Control: cache-extension |
| Connection | Общее поле HTTP заголовка Connection позволяет управлять HTTP соединением | Connection: close |
| Date | Общее поле HTTP заголовка хранит дату и время создания HTTP сообщения | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| MIME-Version | Общее поле HTTPзаголовка MIME-Version содержит версия протокола MIME, по которому было сформировано сообщение. | MIME-Version = «MIME-Version» «:» 1*DIGIT «.» 1*DIGIT |
| Pragma | Общее поле HTTP заголовка Pragma используется для включения особых директив, которые применяются к любому получателю HTTP сообщения. | Pragma: no-cache |
| Trailer | Общее поле HTTP заголовка Trailer хранит в себе список полей, которые имеют отношение к кодированию сообщения и кодированию передачи. | Trailer:field-name |
| Transfer-Encoding | Общее поле HTTP заголовка Transfer-Encoding служит для передачи списка методов кодирования передачи | Transfer-Encoding: chunked |
| Upgrade | Общее поле HTTP заголовкаUpgrade служит для передачи версий , которые поддерживает клиент. Сервер на сообщение со списком отвечает сообщением с одним протоколом | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| Via | Общее поле HTTP заголовкаVia служит для отображения списка , названий и версий прокси-серверов, через которые прошло сообщение. | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Напомню, что поля заголовка объекта HTTP сообщения используются для того, чтобы могли договориться между собой о том, как они будут обмениваться полезной для пользователя информацией и в каком виде эта информация будет представлена. Ниже в таблице в найдете поля заголовка объекта HTTP сообщения. Справочник полей заголовка объекта HTTP сообщения упорядочен по алфавиту.
| Поля HTTP заголовка | Описание поля HTTP заголовка | Пример | Тип HTTP сообщения |
| Allow | Поле заголовка Allow передает клиенту методы, которые тот может использовать | Allow: GET, HEAD, PUT | Ответ |
| Content-Disposition | Поле заголовка Content-Disposition используется для сохранения файлов на сервере | Запрос и ответ | |
| Content-Encoding | Поле заголовка Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия | Content-Encoding: gzip | Запрос и ответ |
| Content-Language | Поле заголовка Content-Language указывает клиенту на каком языке информация, находящаяся в теле объекта. | Content-Language: mi, en | Запрос и ответ |
| Content-Length | Поле заголовка Content-Length указывает необходимую длину тела сообщения в байтах | Content-Length: 3495 | Запрос и ответ |
| Content-Location | Поле заголовка Content-Location используется для идентификации исходного местоположения объекта на сервере. | «Content-Location» «:»absoluteURI | relativeURI) | Запрос и ответ |
| Content-MD5 | Поле заголовка Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения. | Content-MD5: | Запрос и ответ |
| Content-Range | Поле заголовка Content-Range используется в том случае, когда запрашивает фрагмент HTTP сообщение. Данное поле имеет значение байтового диапазона требуемого фрагмента | Content-Range: bytes 88080384-160993791/160993792 | Запрос и ответ |
| Content-Type | Поле заголовка Content-Type используется для указания медиа типа данных в теле сообщения. | Content-Type: text/html;charset=utf-8 | Запрос и ответ |
| Content-Version | Поле заголовка Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется) | Запрос и ответ | |
| Derived-From | Поле заголовка Derived-From это аналог Content-Version (обычно не реализуется) | Запрос и ответ | |
| Expires | Поле заголовка Expires содержит дату и время того момента, когда информация HTTP объекта перестанет быть актуальной | Expires: Tue, 31 Jan 2012 15:02:53 GMT | Запрос и ответ |
| Last-Modified | Поле заголовка Last-Modified содержит дату последней модификации HTTP объекта | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | Запрос и ответ |
| Link | Поле заголовка Link указывает на логически связный с сущностью ресурс (обычно не реализуется) | Запрос и ответ | |
| Title | Поле заголовка Title содержит заголовок объекта | Запрос и ответ |
Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением !
