URL:
User-Agent:
	Ваш браузер Google Chrome Mozilla Firefox Opera Internet Explorer Safari YandexBot YandexMobileBot GoogleBot GoogleBot-Mobile Mail.RU_Bot BingBot Android Webkit Browser Chrome for Android Opera Mobile BlackBerry IE Mobile Очистить (пустой) Можно выбрать User-Agent из списка
Referer:
	Показать html-код страницы

Проверку HTTP заголовков сайта (ответа сервера) лучше выполнять с просмотром html-кода страницы, так как в данном случае используется метод GET, а не HEAD (который возвращает только заголовки), а сервер для разных методов может отдавать разные ответы.

▼ Для справки: коды http-ответов сервера ▼

URL - Единый указатель ресурса (англ. Uniform Resource Locator, URL) - единообразный локатор (определитель местонахождения) ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет.

User Agent - это клиентское приложение, использующее определённый сетевой протокол. Термин обычно используется для приложений, осуществляющих доступ к веб-сайтам, таким как браузеры, поисковые роботы (и другие «пауки»), мобильные телефоны и другие устройства. При посещении веб-сайта клиентское приложение обычно посылает веб-серверу информацию о себе. Это текстовая строка, являющаяся частью HTTP запроса, начинающаяся с User-agent: или User-Agent:, и обычно включающая такую информацию, как название и версию приложения, операционную систему компьютера и язык. У «пауков» эта строка часто содержит URL и email-адрес, по которым веб-мастер может связаться с оператором «паука».

Referer (от ошибочного написания англ. referrer - отсылающий, направляющий) - в протоколе HTTP один из заголовков запроса клиента. Содержит URL источника запроса. Если перейти с одной страницы на другую, referer будет содержать адрес первой страницы. Часто на HTTP-сервере устанавливается программное обеспечение, анализирующее referer и извлекающее из него различную информацию. Так, например, владелец веб-сайта получает возможность узнать, по каким поисковым запросам, как часто и на какие именно страницы попадают люди. Если HTTP-клиент загружает с сервера картинку, представленную на какой-либо странице, то referer будет содержать адрес этой страницы. Некоторые HTTP-серверы перед выдачей картинки анализируют referer и не показывают картинку, если запрос приходит с другого сайта (а, например, показывают маленькое изображение-заглушку). Любопытно, что написание английского слова referrer как referer - популярная ошибка. Настолько популярная, что вошла в официальные спецификации протокола HTTP.

Заголовки HTTP (англ. HTTP Headers) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

Код состояния HTTP (англ. HTTP status code) - часть первой строки ответа сервера при запросах по протоколу HTTP. Он представляет собой целое число из трёх десятичных цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Список кодов состояния HTTP:

1xx Информационные

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

• 100 Continue («продолжай») - сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
• 101 Switching Protocols («переключение протоколов») - сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Upgrade. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
• 102 Processing («идёт обработка») - запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

2xx Успех

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

• 200 OK («хорошо») - успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
• 201 Created («создано») - в результате успешного выполнения запроса был создан новый ресурс. Сервер может указать адреса (их может быть несколько) созданного ресурса в теле ответа, при этом предпочтительный адрес указывается в заголовке Location. Серверу рекомендуется указывать в теле ответа характеристики созданного ресурса и его адреса, формат тела ответа определяется заголовком Content-Type. При обработке запроса, новый ресурс должен быть создан до отправки ответа клиенту, иначе следует использовать ответ с кодом 202. Появился в HTTP/1.0.
• 202 Accepted («принято») - запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
• 203 Non-Authoritative Information («информация не авторитетна») - аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
• 204 No Content («нет содержимого») - сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
• 205 Reset Content («сбросить содержимое») - сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
• 206 Partial Content («частичное содержимое») - сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.
• 207 Multi-Status («многостатусный») - сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
• 226 IM Used («использовано IM») - заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

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

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI. По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход. Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

• 300 Multiple Choices («множество выборов») - по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
• 301 Moved Permanently («перемещено навсегда») - запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
• 302 Moved Temporarily («перемещено временно»), 302 Found («найдено») - запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
• 303 See Other (смотреть другое) - документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
• 304 Not Modified (не изменялось) - сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
• 305 Use Proxy («использовать прокси») - запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
• 306 (зарезервировано) - использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
• 307 Temporary Redirect («временное перенаправление») - запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx Ошибка клиента

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

• 400 Bad Request («плохой, неверный запрос») - сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
• 401 Unauthorized («не авторизован») - для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.
• 402 Payment Required «необходима оплата») - предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.
• 403 Forbidden («запрещено») - сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401, или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам.htaccess или.htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
• 404 Not Found («не найдено») - самая распространённая ошибка при пользовании Интернетом, основная причина - ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
• 405 Method Not Allowed («метод не поддерживается») - указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
• 406 Not Acceptable («неприемлемо») - запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
• 407 Proxy Authentication Required («необходима аутентификация прокси») - ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
• 408 Request Timeout («истекло время ожидания») - время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
• 409 Conflict («конфликт») - запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.
• 410 Gone («удалён») - такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
• 411 Length Required («необходима длина») - для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
• 412 Precondition Failed («условие ложно») - возвращается, если ни одно из условных полей заголовка (If-Match и др., см. RFC 7232) запроса не было выполнено. Появился в HTTP/1.1.
• 413 Request Entity Too Large («размер запроса слишком велик») - возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
• 414 Request-URL Too Long («запрашиваемый URI слишком длинный») - сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.
• 415 Unsupported Media Type («неподдерживаемый тип данных») - по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
• 416 Requested Range Not Satisfiable («запрашиваемый диапазон не достижим») - в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).
• 417 Expectation Failed («ожидаемое неприемлемо») - по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
• 418 I"m a teapot («Я чайник») - Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.
• 422 Unprocessable Entity («необрабатываемый экземпляр») - сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
• 423 Locked («заблокировано») - целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
• 424 Failed Dependency («невыполненная зависимость») - реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
• 425 Unordered Collection («неупорядоченный набор») - используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.
• 426 Upgrade Required («необходимо обновление») - сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
• 428 Precondition Required («необходимо предусловие») - сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
• 429 Too Many Requests «слишком много запросов») - клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
• 431 Request Header Fields Too Large («поля заголовка запроса слишком большие») - Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
• 434 Requested host unavailable «Запрашиваемый адрес недоступен») - Запрашиваемый адрес недоступен.
• 449 Retry With («повторить с») - возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
• 451 Unavailable For Legal Reasons («недоступно по юридическим причинам») - доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту». Был добавлен в стандарт 21 декабря 2015.

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

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

• 500 Internal Server Error («внутренняя ошибка сервера») - любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
• 501 Not Implemented («не реализовано») - сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
• 502 Bad Gateway («плохой, ошибочный шлюз») - сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.
• 503 Service Unavailable («сервис недоступен») - сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
• 504 Gateway Timeout («шлюз не отвечает») - сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
• 505 HTTP Version Not Supported («версия HTTP не поддерживается») - сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
• 506 Variant Also Negotiates («вариант тоже проводит согласование») - в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
• 507 Insufficient Storage («переполнение хранилища») - не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
• 508 Loop Detected («обнаружено бесконечное перенаправление») - обнаружено бесконечное перенаправление.
• 509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала») - используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
• 510 Not Extended («не расширено») - на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
• 511 Network Authentication Required («требуется сетевая аутентификация») - этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником - например, сервером провайдера - в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

Список заголовков HTTP в ответах сервера:

Заголовок

Назначение	Пример
Accept-Ranges	Cообщает клиенту о том, что он может запрашивать данные с сервера фрагментами, указывая их смещение в байтах	Accept-Ranges: bytes Accept-Ranges: none
Age	Возраст документа в кэше прокси в секундах	Age: 12
Allow	Список поддерживаемых методов.	Allow: GET, HEAD
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	Заголовок используется для управления текущим соединением.	Connection: close Connection: keep-alive Connection: Upgrade
Content-Encoding	Способ кодирования содержимого документа при передаче.	Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: identity Content-Encoding: br
Content-Language	Один или несколько естественных языков содержимого документа.	Content-Language: en, hi, ru
Content-Length	Размер передаваемого документа в байтах.	Content-Length: 7529
Content-Location	Указывает альтернативное расположение для возвращаемого документа.	Content-Location: /index.html
Content-MD5	MD5-сумма в кодировке Base64 документа для проверки целостности.	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	Байтовые диапазоны передаваемого документа если возвращается фрагмент.	Content-Range: bytes 88080384-160993791/160993792
Content-Type	Указывает mime-type документа и кодировку в которой передаётся текст	Content-Type: image/gif Content-Type: text/html;charset=utf-8
Content-Version	Информация о текущей версии документа.
Date	Дата генерации ответа сервера.	Date: Sun, 30 Oct 2016 17:11:31 GMT
ETag	Уникальный идентификатор документа, используемый при кэшировании в браузере.	ETag: "56d-9989200-1132c580"
Expires	Дата предполагаемого истечения срока актуальности документа.	Expires: Sun, 30 Oct 2017 17:11:31 GMT
Last-Modified	Дата последней модификации документа.	Last-Modified: Mon, 26 Sep 2016 02:02:31 GMT
Link	Указывает на логически связанный с документом ресурс аналогично тегу в HTML.	Link: ; rel="https://api.w.org/"
Location	URI по которому клиенту следует перейти. Заголовок используется для редиректа при .	Location: https://сайт/tools/httpheaders.php
Pragma	Используется только для обратной совместимости с HTTP/1.0 клиентами.	Pragma: no-cache
Retry-After	Дата или время в секундах после которого можно повторить запрос.	Retry-After: Wed, 21 Oct 2015 07:28:00 GMT Retry-After: 120
Server	Список названий и версий веб-сервера и его компонентов с комментариями.	Server: nginx/1.10.1
Set-Cookie	Заголовок используется для установки и обновления cookie в браузере	Set-Cookie: qwerty=219ffwef9w0f; Domain=сайт; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
Status	Заголовок, определяющий код состояния ответа HTTP.	Status: 200 OK
Trailer	Список полей, имеющих отношение к кодированию сообщения при передаче.	Trailer: Expires
Transfer-Encoding	Список способов кодирования, которые были применены к документу для передачи.	Transfer-Encoding: chunked
Upgrade	Список предлагаемых клиентом протоколов. Сервер указывает один протокол.	Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
Vary	Список полей из запроса, которые были приняты сервером во внимание.	Vary: * Vary: Accept-Encoding
Via	Список версий протокола, названий и версий прокси-серверов, через которых прошло сообщение.	Via: 1.0 fred, 1.1 сайт
Warning	Код, агент, сообщение и дата, если возникла критическая ситуация.	Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"

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

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

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

Ответ сервера и его составляющие, которые могут повлиять на SEO

В статье, объясняющей суть передачи данных посредством протокола HTTP (HTTPS), ссылка на которую дана в начале публикации, я писал о том, как в принципе происходит общение , которое основывается на схеме «запрос клиента — ответ сервера» .

Напомню вкратце, как это осуществляется. Браузер, после того, как пользователь вводит в адресную строку URL страницы, обращается в ближайший ДНС сервер, где хранятся списки всех доменов (), а также соответствующие им IP-адреса (каждое устройство в интернете имеет , включая серверы, где "живут" сайты).

Получив нужный IP, браузер посылает на соответствующий этому ай-пи сервер запрос GET для получения нужного содержания. Серверное ПО обрабатывает запрос и высылает ответ, включающий содержание вебстраницы в виде HTML-кода, который затем модифицируется веббраузером для отображения контента странички в удобоваримом виде.

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

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

Чтобы практически осуществить проверку ответа сервера на запрос робота поисковой системы Яндекс, можно воспользоваться специальным инструментом , где вводите URL исследуемой страницы, а также выбираете нужного бота из выпадающего списка (кроме основного там присутствуют роботы по зеркалам, по картинкам, по поиску видео и другие):

Чуть ниже я расскажу подробнее, что полезного можно почерпнуть из этих данных. Ведь если мы это поймем, то можем узнать, по какому пути двигаться в плане SEO оптимизации страниц сайта. Ну и обратим внимание на другие онлайн сервисы, посредством которых можно проверить код ответа сервера и просмотреть содержание HTTP заголовков.

HTTP коды состояния — 200, 301, 302, 403, 404, 500 и другие

Код состояния, приходящий в ответе сервера, определяет статус вебстраницы сайта, в отношении которой клиентское приложение отправляет запрос на сервер. Например, HTTP 200 OK означает, что все все содержимое странички передано и будет доступно для просмотра.

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

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

1. 1XX — информационные, в которых сервер сообщает о процессе обработки запроса.

2. 2XX — HTTP коды, информирующие об успешно переданных данных. О 200 OK я уже упомянул, остальные являются его производными.

3. 3XX — переадресация различного вида с одного URL на другой. Например, если 301 означает, что адрес страницы изменен навсегда, то код 302 говорит о временном перенаправлении. В отличие от постоянного 302 редирект не является сигналом поисковым системам для передачи веса страницы со старого адреса, поэтому на практике он используется лишь в исключительных ситуациях, когда является наиболее оптимальным решением.

4. 4XX — HTTP коды ошибок в запросе со стороны клиента. Например, всем известный код статуса 404 означает, что документа по такому адресу на хосте нет.

5. 5XX — ошибка на сервере, в результате которой страница не может быть предоставлена.

Более подробный список кодов состояния, предоставляемых в HTTP ответе сервера, вы можете получить, если посетите соответствующую страницу Википедии .

Важность правильного статуса страниц веб-ресурса очень сложно переоценить. Поэтому время от времени старайтесь проверять коды ответов сервера для страничек своего сайта, это может оградить вас от многих неприятностей.

Бывали случаи, например, когда сервер отвечает HTTP кодом 404 вместо ожидаемого 200 , поскольку в реальности вебстраницы доступны и прекрасно открываются. Если такая ситуация, не дай бог, сложится при ответе сервера на запрос того же робота Яндекса, то вполне вероятно, произойдет выпадение этих страниц из индекса, что будет очень обидно.

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

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

Если взгляните на скриншот выше, где дан ответ сервера, то увидите, что чуть ниже строки с кодом статуса присутствует пояснение, включающее информацию о времени ответа сервера, IP-адресе сайта, кодировке и размере страницы:

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

Какой же должна быть величина времени отклика? Гугл, например, определяет максимальную границу в 200 мс (миллисекунд), но, конечно, чем меньше, тем лучше. Как же увеличить скорость ответа сервера? Для начала попробуйте провести некоторые мероприятия по , вполне возможно, что проблему решит установка плагина кеширования.

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

HTTP заголовки и их значение

В этом свете будем рассматривать примеры ответов на запросы роботов поисковых систем , поскольку они интересуют нас в первую очередь. Для наглядности вначале представляю скриншот с HTTP заголовками, соответствующими урлу страницы со статусом 200 ОК:

Server — название и версия веб-сервера. В данном примере это nginx, который в силу малого использования ресурсов и гибкости конфигурирования решает задачу оптимизации работы основного сервера Apache и используется с ним в связке.

Date — дата и время возврата содержания запрашиваемой страницы.

Content-Lenght — объем передаваемого контента в байтах ().

Connection — соединение. Параметр keep-alive означает, что после выдачи документа соединение с сервером не разрывается и можно отправлять дополнительные запросы.

Vary — этот заголовок позволяет выдать правильный документ при наличии нескольких его версий. Он актуален, например, при применении технологии сжатия страниц, когда в кеше хранится и сжатая, и несжатая версия. При ответе Accept-Encoding в кеше будут находиться различные варианты запрошенной страницы для разных клиентских приложений (агентов).

Cache-Control — управление кешированием. В нашем образце этот заголовок отражает вид кеша, в котором располагается документ (public) и время, в течении которого он должен находиться в кеше (max-age). Значение public указывает, что эта операция применяется к файлам, хранящимся в общедоступном кэше. Параметр max-age выдает время в секундах.

X-Hyper-Cache — специальный заголовок, который многие пользователи WordPress, наверное, сразу идентифицировали. Несомненно, он касается работы , который я считаю, пожалуй, лучшим в своем классе. Значение «hit - gzip» показывает, что к кешированной странице применено сжатие методом gzip.

Content-Encoding — способ кодирования (в общем смысле) передаваемого в ответе содержания страницы. В нашем примере было применено сжатие gzip. Это сигнал клиентской программе (User Agent) распаковать содержимое для его корректного восприятия.

А теперь я отмечу заголовки ответа, на содержание которых вебмастерам следует обратить особое внимание, поскольку оно может оказать серьезное влияние на продвижение. Причем, если вы используете в качестве управления контентом сайта , с помощью которого HTML-странички генерируются "на лету", то с большой долей вероятности при наличии проблемы у одной вебстраницы пострадают и остальные.

Content-Type — тип контента, который в этом примере представляет из себя HTML-код в кодировке UTF-8. Некорректное указание кодировки может привести к сложностям в восприятии текста пользователями и ботами ПС, а это чревато непопаданием страницы в индекс.

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

Last-Modified — дата последней модификации веб-страницы. Если клиент (в нашем случае робот Яндекса) получил от сервера этот заголовок с датой обновления контента, то при следующем обращении к URL этой же страницы он отправит серверу в составе запроса If-Modified-Since .

Вебсервер выделит промежуток от времени последних изменений до времени, указанного в заголовке If-Modified-Since. Ежели за этот период страница никоим образом не была изменена, то сервер отправит ответ с HTTP кодом 304 Not Modified , причем в этом случае содержание страницы отправлено не будет. Если же редактирование имело место, то робот получит код 200 ОК вместе с измененным контентом.

Этот механизм, если он настроен верно, позволяет выдавать постоянно свежую информацию. Ведь тут важна актуальность данных, что и обеспечивается правильной реализацией проверки времени последнего обновления. Ведь при неправильной настройке (если дата, указанная в Last-Modified не меняется) робот может получить просто код 304 Not Modified (вместо 200 OK с новой версией документа), хотя контент был несколько раз отредактирован.

Как же можно проверить корректность работы Last-Modified для сервера, на котором расположен ваш сайт? Попробуем разобраться на конкретном примере .

На том же сервисе Яндекса, ссылку на который я уже предложил выше, есть специальная опция, которая позволяет добавить запрос If-Modified-Since и указать нужные вам дату и время (в формате GMT, то есть по Гринвичу, относительно часового пояса Москвы это -3 часа) вплоть до минут, которое определит временной интервал проверки на обновление:

Взгляните на 10 скриншот вверх отсюда, где дан результат проверки в отношении урла одной из страниц моего блога (где отмечены все разделы ответа сервера). Там в части заголовков дано определенное значение Last-Modified, то есть дата последнего обновления. Теперь я включаю показатель If-Modified-Since в запрос и проверяю ответ сервера:

Как видите, получен код 304 Not Modified без содержания вебстраницы, что совершенно верно для данной ситуации, поскольку контент действительно не был обновлен за данный период. Далее для тестирования я добавил небольшой фрагмент текста в этой статье.

Затем я вновь послал запрос от робота Яндекса на сервер, который при правильно работающем механизме кэширования (после обновлении страницы в кеше присутствует последняя версия) должен возвратить ответ 200 ОК с новым содержанием, что и произошло:

Для полного успокоения можно еще просмотреть содержимое заголовка Content-Lenght, которое показывает, что объем контента незначительно, но увеличился (18443 против 18437 до редактирования). Это соответствует действительности, поскольку я именно добавил толику текста. Точно так же вы можете проверить правильность настройки заголовков для своего сервера.

Location — еще один заголовок, который я хотел бы отметить для полноты информации по этой теме. Он появляется в ответе сервера в том случае, ежели робот посылает запрос в отношении вебстраницы, с которой было совершено постоянное перенаправление (HTTP код 301):

Новый адрес, на который был проставлен редирект, и будет присутствовать в заголовке Location. Содержимое страницы в ответе отсутствует, что вполне логично, а вот в пояснении, которое следует за кодом ответа 301 Moved Permanently, указан размер страницы, на урл которой осуществляется переадресация.

Проверка ответа сервера в онлайн сервисах

Далее для полноты картины нелишним будет отметить online сервисы, которые позволяют проверить HTTP ответ сервера. На просторах интернета мне приглянулся вот этот (Checkmy.ru), который обладает достойным функционалом. Проверим теперь на нем отклик сервера, но уже на запрос робота Google для разнообразия:

После активации процесса чуть ниже вы получите ответ со всеми раскладами:

Сервис Checkmy предлагает пользователям не только выбор приложения (User Agent), с которого будет отправлен запрос, но и использования заголовков If-Modified-Since и Accept-Encoding, о которых велась речь выше.

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

На сайте есть еще такая фишка как закладка для браузера, которая обеспечит скоростную проверку любой веб-страницы, на которую вы перейдете. Для этого достаточно прокрутить страницу вниз до нужного места, нажав на ссылку «Быстрый доступ» из верхнего меню. Затем, захватив левой кнопкой мышки кнопку «Checkmy» , переместить ее на панель закладок браузера:

В заключение отмечу еще сервис, с помощью инструмента которого удачно осуществите массовую проверку отклика сервера сразу для 200 URL, причем есть возможность загрузки архива ZIP с урлами. А на десерт видеролик о том, что такое код 404 Soft и чем он опасен для вебмастеров:

Заголовки HTTP используются для "общения" браузера и web-сервера, например, когда браузер запрашивает какой-либо документ, он посылает заголовок GET, а когда сервер возвращает тип документа, то он делает это ни как-нибудь, а в заголовке Content-type.

Мы уже частично рассматривали заголовки протокола HTTP, но теперь остановимся на них подробнее.

Итак, приведем список и краткое описание основных заголовков HTTP.

Заголовок Accept

Заголовок Accept предназначен для информирования сервера о типах данных, которые поддерживаются клиентом (браузером). В этом заголовке браузер перечисляет, какие типы документов он "понимает". Пере-
числение идет через запятую.

Используется переменная окружения HTTP_ACCEPT. Пример использования:

Accept: text/html, text/plain, image/jpeg

В последнее время вместо списка указывается значение *.*, что означает "все типы".

Заголовок Content-type

Данный заголовок предназначен для идентификации типа передаваемых данных. При этом заголовок Content-type использует переменную окружения CONTENT_TYPE. Обычно для этого заголовка указывается значение application/x-www-form-urlencoded. Таким образом, указывается формат, в котором все управляющие символы (т.е. символы, не являющиеся алфавитно-цифровыми) специально кодируются. О некоторых других MIME-типах вы можете узнать .

Это тот самый формат передачи, который используется методами GET и POST .

Довольно распространен и другой формат, multipart/form-data.

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

Пример: Content-type: text/plain

Заголовок Content-length

Этот заголовок содержит строку, в которой записана длина передаваемых данных в байтах при использовании метода передачи POST. За заголовком закреплена одноименная переменная CONTENT_LENGTH.

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

Заголовок Cookie

В этом заголовке хранятся все Cookies . Данный заголовок использует переменную окружения HTTP_COOKIE. Для установки Cookies используется заголовок Set-Cookie.

Заголовок GET

Об этом заголовке мы упоминали ранее.

Заголовок GET использует следующие переменные окружения:

• REQUEST_URI - запрашиваемый идентификатор ресурса;
• QUERY_STRING - передаваемые сценарию параметры;
• REQUEST_METHOD - метод передачи информации. В данном случае эта переменная будет содержать значение GET.

Заголовок Location

Получив заголовок Location вместе с указанным в нем URL, сервер немедленно переходит по указанному URL, не дожидаясь, пока тело документа загрузится:

Пример: Location: http://www.somehost.com/

Заголовок POST

Этот заголовок использует те же переменные окружения, что и заголовок GET (переменная REQUEST_METHOD содержит значение POST). Напомним, что данные методом POST можно передавать в конце заголовков.

Напомним формат заголовка POST: POST сценарий?параметры HTTP/1.0

Заголовок Pragma

Данный заголовок используется для различных целей, одна из которых - это запрет кэширования документа.

Пример заголовка: Pragma: no-cache

Заголовок Server

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

Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b Dav/1.0.3 PHP/4.3.0 mod_perl/1.26 configured

Заголовок Referer

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

Заголовок User-Agent

Содержит версию браузера. Например: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux).

Переменная окружения: HTTP_REFERER.

Некоторые комментарии по HTTP-заголовкам

Мы ознакомились с названиями заголовков и соответствующим им переменным окружения.

Необходимо помнить основные приципы:

• Все символы в верхнем регистре;
• В начале имен добавляется HTTP_
• Символы "-" заменяются знаком подчеркивания "_".

Передача заголовков HTTP в PHP

В PHP есть встроенные функции для работы с заголовками HTTP.

Для передачи заголовков HTTP предназначена функция header()

Приведем практические примеры:

header (" Content-type: text/plain " );
?>

header ("Location: http://www.example.com/" ); /* Производит перенаправление браузера на другой ресурс */

/* Внимание! Убедитесь, что код, расположенный ниже не исполняется */
exit;
?>

// Date in the past
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT" );

// always modified
header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" ) . " GMT" );

// HTTP/1.1
header ("Cache-Control: no-store, no-cache, must-revalidate" );
header ("Cache-Control: post-check=0, pre-check=0" , false );

// HTTP/1.0
header ("Pragma: no-cache" );
?>

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

Все статьи из цикла:

• Что такое Http заголовки. Общая теория.

HTTP расшифровывается как HyperText Transfer Protocol (протокол передачи гипертекста). Протокол — это набор правил, по которым разные устройства обмениваются данными. Он был создан в 1990-х годах. Сейчас он используется в сети интернет практически повсеместно. Всё, что вы видите в окне браузера, было получено посредством этого протокола. http заголовки — пожалуй главная вещь в общении между устройствами. Они передают основную информацию об устанавливающемся соединении и о передаваемой информации через это соединение.
Взглянем на схему общения двух устройств. Пусть этими устройствами будут ваш компьютер и какой-нибудь сервер в интернете:

Как видно, браузер отослал http-запрос. Он может выглядеть примерно так:

GET /other-19 HTTP/1.1 Host: www.scriptsite.ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

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

Server: Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.8k mod_dp20/0.99.2 PHP/5.2.5 mod_python/3.3.1 Python/2.5.1 mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24) X-Powered-By: PHP/5.2.5 Set-Cookie: PHPSESSID=ft47gokfee6amv3eda3k1p93s3; path=/ Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Keep-Alive: timeout=10, max=1024 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html

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

Как увидеть http-заголовки?

Для того, чтобы увидеть http-заголовки, я рекомендую следующие плагины для браузера firefox:

Если вы пользуетесь браузером Chrome, просмотреть всю информацию можно, нажав на кнопку настройки — инструменты — инструменты разработчика. Вкладка networks.
Пользователям браузера opera ничего посоветовать не могу, так как не дружу с этим браузером. Установив плагины и запустив их, попробуйте обновить страницу. Вы сразу же увидите огромные списки запросов и ответов, посредством которых ваш браузер общался с сервером.

Http-заголовки и доступ к ним в php

Если вы являетесь php-разработчиком, вы можете получить доступ к заголовкам запроса с помощью функции getallheaders() . Для понимания её работы выполним такой код:

И мы получаем распечатку массива заголовков.

Но чаще к ним обращаются через глобальную переменную $_SERVER. Почти для каждого http заголовка есть аналогичное название элемента в этой переменной, образуемого по принципу HTTP_имя_заголовка. Так для того же ‘User_Agent’ есть переменная $_SERVER[‘HTTP_USER_AGENT’];

Для получения заголовков, которые сервер собирается отправить пользователю, используется функция headers_list() . Как правило, сервер составляет недостающие обязательные заголовки уже в конце работы всех скриптов. Поэтому этот массив будет содержать заголовки либо те, которые сервер создал перед началом выполнения скрипта (и они не будут изменены), либо те, которые мы установили вручную. Вручную их можно установить с помощью функции header(«текст заголовка»);
Выполним такой код:

Увидим распечатку готовых к отправке на момент вызова функции заголовков:

Первый заголовок был установлен автоматически, и он несёт в себе название сервера, на котором выполняется скрипт. Второй - установленный нами вручную. Если бы браузеру нужен был заголовок «Фрукт», он бы взял его из http-ответа сервра и использовал. Но так как наш браузер не нуждается в нём, то он просто игнорирует непонятную ему строку.

Структура http запроса

Наш запрос выглядит следующим образом:

Первая строка в нём, как уже было сказано раньше, является строкой запроса. Она состоит из трёх частей:

• method (метод) — указывает, какого рода запрос. Самые распространённые методы: GET, POST, HEAD. О них будет написано в следующем параграфе.
• path (путь) — как правило, это часть URL, идущая после домена. Например, если вы вводите в адресную строку http://www.scriptsite.ru/about/, значение path будет /about/.
• protocol (протокол) — используемый протокол. Как правило, состоит из «HTTP» и версии протокола. Обычно, в современных браузерах используется версия 1.1

Дальше идут заголовки в виде строк формата «Имя: значение».
Кстати, данные о cookies также передаются в этом запросе в виде одного из заголовков. Большинство из этих строк не являются обязательными. Запрос может быть сокращён вообще до двух строк:

GET /article/show/4/ HTTP/1.1 Host: scriptsite.ru

Методы запроса

GET

get-запрос обычно используется для запроса документа с передачей некоторых параметров.
Это основной метод, используемый для получения html-страниц, изображений, CSS и JavaScript файлов, и т.д.
Из-за того, что параметры могут быть любыми, а на сервере нет ограничений по способам их обработки, часто метод для запросов данных используют для передачи информации. Например, у нас будет такая форма

При этом эти параметры будут видны в адресной строке браузера.

POST

Post — метод, используемый для отправки данных на сервер. Несмотря на то, что вы можете отправлять данные серверу методом GET через адресную строку браузера, в большинстве случаев предпочтительнее использовать POST. Отправлять большие объёмы данных через GET непрактично. К тому же GET имеет некоторые ограничения, не позволяющие, например, опубликовать эту статью на моём сайте через одну лишь строку браузера. POST запросы чаще всего используются для передачи web-форм. Давайте изменим форму из предыдущего примера, задав ей метод POST

Заголовки Content-Type и Content-Lenght добавлены автоматически. Они содержат информацию о типе и размере данных.
Все данные передаются после отправки заголовков в таком же виде, как в строке запроса GET

Метод POST повсеместно используется в AJAX, cURL, и т.д.
Формы загрузки файлов работают только через метод POST

HEAD

Многие из вас могли и не знать об этом типе запросов.
Этот метод работает аналогично post, только сервер не возвращает никакого дополнительного содержимого, кроме заголовков.
Использование этого заголовка бывает оправдано во многих случаях. Например, когда браузер когда-то закешировал файл, а теперь хочет узнать, не изменился ли тот на сервере. Браузер может запросить информацию о нём, не скачивая сам файл полностью.
Кроме того, этот метод часто используется в сервисах, проверяющих ссылки на работоспособность. Он позволяет узнавать, по каким URL адресам ещё есть файлы, а по каким их уже нет, при этом опять же файлы не скачиваются.

Структура http ответа

Сервер отвечает на каждый запрос такими ответами:

Первая строка — версия протокола.
Далее указывается код статуса сервера. В данном значение кода равно 200. Код статуса показывает браузеру, что именно произошло на сервере во время обработки запроса. 200й статус означает, что наш запрос был успешно обработан, и сервер отправит запрашиваемый документ сразу после передачи заголовков.
В остальных строчках указывается всевозможная информация о передаваемом файле.

К информации о статусах можно ещё добавить факт об ошибке 404. Её название пошло именно из кода 404, который отсылает сервер, когда не может найти файл на своих дисках.
Более подробно о статусах сервера написано в следующей статье.

Обратите также внимание

URL:
User-Agent:

Показать html-код страницы
Кодировка: Автоопределение UTF-8 ISO-8859-1 Windows-1251 KOI8-R

Консольная команда для вывода заголовков:
curl -I http://сайт

Список кодов ответа сервера

Код состояния 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
(русск. Не расширено )
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.