Что такое http заголовок? Методы HTTP запроса. Список кодов состояния HTTP

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

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

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: (введён Microsoft) и (введён в cPanel).

Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.

Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается - он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе "Коды состояния служб IIS" в Базе знаний Microsoft.

1xx: Informational (Информационные)

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

100 Continue (Продолжать) - Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101 Switching Protocols (Переключение протоколов) - Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing (Идёт обработка) - Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) - При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

2xx: Success (Успешно)

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

200 OK (Хорошо) - Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201 Created (Создано) - В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом . Появился в HTTP/1.0.

202 Accepted (Принято) - Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203 Non-Authoritative Information (Информация не авторитетна) - Аналогично ответу , но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в 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: Redirection (Перенаправление)

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

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

Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами и ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды и вместо . Изменять метод нужно только если сервер ответил . В остальных случаях следующий запрос производить с исходным методом.

300 Multiple Choices (Несколько вариантов выбора) - По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301 Moved Permanently (Перемещено навсегда) - Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302 Moved Temporarily / Found (Перемещено временно / Найдено) - Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303 See Other (Смотреть другое) - Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом , указав в заголовке 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 заголовка. Этот код был введён вместе с вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx: Client Error (Ошибка клиента)

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

400 Bad Request (Плохой запрос) - Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401 Unauthorized (Неавторизован) - Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402 Payment Required (Необходима оплата) - Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 Forbidden (Запрещено) - Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ или при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам.htaccess или.htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404 Not Found (Не найдено) - Самая распространенная ошибка при пользовании Интернетом, основная причина - ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код . Ответ может использоваться вместо , если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405 Method Not Allowed (Метод не поддерживается) - Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код (Not Implemented). Появился в HTTP/1.1.

406 Not Acceptable (Неприемлемо) - Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407 Proxy Authentication Required (Необходима прокси авторизация) - Ответ аналогичен коду за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408 Request Timeout (Истекло время ожидания) - Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409 Conflict (Конфликт) - Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410 Gone (Удалён) - Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код . Появился в HTTP/1.1.

411 Length Required (Необходима длина) - Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412 Precondition Failed (Условие ложно) - Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.

413 Request Entity Too Large (Размер запроса слишком велик) - Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414 Request-URI Too Large (Запрашиваемый 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 (Слишком много запросов) - Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком 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 градус по Фаренгейту".

456 Unrecoverable Error (Некорректируемая ошибка) - Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 () - Используется Nginx, когда клиент закрывает соединение до получения ответа.

5xx: Server Error (Ошибка сервера)

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

500 Internal Server Error (Внутренняя ошибка сервера) - Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501 Not Implemented (Не реализовано) - Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ . Появился в 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.

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

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

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

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

• 100 - сервер принял первую часть запроса, можно подрожать передачу;
• 101 - нужно изменить протокол работы на более подходящий;
• 102 - на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх - операция успешна:

• 200 - запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
• 201 - после выполнения запроса был создан ресурс;
• 202 - запрос принят, но еще не обработан;
• 203 - запрос выполнен успешно, но информация для ответа взята из прокси;
• 204 - запрос обработан, но контента для отображения нет;
• 205 - попросить пользователя ввести необходимые данные;
• 206 - запрос обработан, но передана только часть контента;

3xx - перенаправления:

• 300 - есть несколько страниц для этого запроса, например, на нескольких языках;
• 301 - страница навсегда перемещена по новому адресу;
• 302 - документ был временно перемещен;
• 303 - документ необходимо загрузить по указанному адресу с помощью протокола GET;
• 304 - документ не изменился с последнего запроса;
• 305 - нужно использовать прокси;
• 307 - ресурс временно перемещен на новый адрес.

4хх - ошибка в запросе:

• 400 - неверный запрос;
• 401 - необходимо аутентифицироваться;
• 403 - запрос принят, но у вас нет доступа;
• 404 - страница не найдена на сервере;
• 405 - используемый метод нельзя применять на сервере;
• 408 - время ожидания передачи запроса истекло;
• 410 - ресурс полностью удален;
• 411 - нужно указать длину запроса;
• 413 - запрос слишком длинный;
• 414 - URI запроса слишком длинная.

5хх - ошибка сервера:

• 500 - внутренняя ошибка сервера;
• 501 - нужная функция не поддерживается;
• 502 - прокси не может соединиться со шлюзом;
• 503 - сервер не может обрабатывать запросы по техническим причинам;
• 504 - прокси не дождался ответа от сервера;
• 505 - версия протокола HTTP не поддерживается.

Что такое http заголовки?

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

• Server - имя и версия веб-сервера;
• Date - дата осуществления запроса;
• Content-Type - MIME тип передаваемых данных, например, text/html, тут же задается кодировка;
• Connection - тип соединения, может быть closed - уже закрыто, или keep-alive - открыто для передачи данных;
• Vary - указывает при каких заголовках веб-сервер будет возвращать разные старины для одного URI;
• Set-Cookie - сохранить Cookie информацию для страницы;
• Expires - можно хранить страницу или ресурс в кэше до определенной даты;
• Cache-Control - настройка времени кэширования страницы браузером, а также разрешения на кэширования;
• ETag - содержит контрольную сумму для страницы, применимо для проверки кэша;
• Last-Modified - дата, когда страница последний раз была изменена;

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

Проверка кода ответа сервера с помощью cURL

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

curl -s -o /dev/null -w "%{http_code}" https://сайт

Или, если хотите, чтобы ответ выглядел более естественно:

curl -I https://сайт 2>

Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:

curl -I http://сайт 2>/dev/null | head -n 1 | cut -d$" " -f2

curl -I https://www.сайт 2>/dev/null | head -n 1 | cut -d$" " -f2

Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

curl -I https://сайт

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

• Страница сгенерирована в nginx 1.10.2;
• Это обычная html страница (text/html);
• Размер страницы 102452 байт или 100 кб;
• Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
• Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
• Страница может храниться в любом кэше (public) на протяжении часа (expires);

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

curl -I https://сайт/wp-content/uploads/2016/08/map-2.png

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй - по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

curl -I https://сайт

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

curl -I https://сайт

Затем отправим полученную сумму с заголовком:

curl -I --header "If-None-Match: "58615db8-19034"" https://сайт

И снова мы должны получить ответ 304, страница не изменена.

Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

curl -I https://сайт --header "Accept-Encoding: gzip"

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Выводы

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

Об авторе

Основатель и администратор сайта сайт, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux интересуюсь всем, что связано с информационными технологиями и современной наукой.

Для чего предназначен инструмент "Проверка заголовков сервера"?

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

Что такое заголовки сервера и для чего они нужны?

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

Как работает инструмент "Проверка HTTP статусов" и для чего он нужен?

После того, как вы введете адрес ресурса и нажмете кнопку "Показать", сервер обработает запрос и выдаст результат. В самой верхней строке ответа вы увидите состояние (статус) сервера: например, HTTP/1.1 200 OK.

Что такое статус сервера?

Статусов у сервера – четыре, и они сгруппированы по назначению.

Коды 2xx обозначают, что запрос обработан успешно, и вы сможете узнать более подробную информацию о ресурсе.

Коды 3xx обозначают, что сервер перенаправил запрос и получить информацию о ресурсе можно другим способом.

Коды 4xx – это самая обширная группа статусов сервера, которая обозначают, что в запросе допущена ошибка.

Коды 5xx обозначают, что в работе запрашиваемого сервера произошел какой-то сбой, и получение информации об интересующем ресурсе пока невозможно.

Более подробно о статусах запросов вы можете узнать из таблицы "Перечень кодов HTTP" ниже.

Что такое метод GET и метод POST?

Существует три типа запросов, принимаемых сервером: GET, POST и HEAD, но мы поговорим о наиболее распространенных – первых двух. Третий метод используется достаточно редко, потому как HEAD запрашивает только заголовок ответа, а полноценный обмен данными при этом не происходит. Метод GET используется при запросе к серверу по умолчанию, а POST – только при однозначном указании в запросе формы. Веб-мастера должны учитывать, что при запросе методом GET серверу передаются все данные формы вместе с URL, а при использовании метода POST данные перемещаются не в URL, а в само тело запроса.

Коды 2xx (успешно)

Перечень кодов статуса HTTP, использующихся при успешном запросе (коды 2xx).

Коды 3xx (перенаправление)

Перечень кодов статуса HTTP, использующихся при перенаправлении запроса (коды 3xx).

Коды 4xx (ошибка клиента)

Содержит перечень кодов статуса HTTP, использующихся для обозначения возможных ошибок в клиентском запросе (коды 4xx).

Коды 5xx (ошибка сервера)

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

Проверку 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:

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

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

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

• 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 поддержкой дельта-кодирования.

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому 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 предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме 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 выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода 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 в ответах сервера:

Заголовки 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" );
?>