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

HTTP

предисловие

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

HTTP decision diagram

Картинка относительно размыта, сжата, включите GitHubfor-GET/http-decision-diagramСмотрите исходное изображение проекта.

100 Continue

Указывает, что пока все в порядке, клиент должен продолжить запрос или игнорировать, если запрос был выполнен.

Чтобы сервер мог проверить заголовки запроса, клиент ДОЛЖЕН отправить заголовок Expect: 100-continue в запросе инициализации и получить код состояния ответа 100 Continue перед отправкой объекта запроса.

Expect

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

Только желаемое условие указано в спецификации, что ожидается: 100 - продолжить, что может сделать следующий ответ на этот сервер:

  • 100 Если ожидаемые условия в заголовке сообщений могут быть выполнены, чтобы запрос мог пройти плавно,
  • 417 (ошибка ожидания) Если сервер не соответствует ожидаемым условиям, это также может быть любой другой код состояния (4xx), указывающий на ошибку клиента.

101 Switching Protocols

Указывает, что сервер выполняет переключение протокола в ответ на запрос клиента на обновление протокола (заголовок запроса на обновление). пример:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket 
Connection: Upgrade

200 OK

Указывает, что запрос выполнен успешно. Ответы с кодом состояния 200 могут кэшироваться по умолчанию.

201 Created

Указывает, что запрос успешно обработан и создан новый ресурс. Новый ресурс был создан до того, как был возвращен ответ.

202 Accepted

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

204 No Content

Указывает, что в настоящее время запрос выполнен успешно, но клиенту не нужно обновлять существующую страницу.

Соглашение об использовании состоит в том, чтобы обновить ресурс в запросе PUT, но не нужно менять страницу, отображаемую в данный момент пользователю, а затем возвращать 204 No Content. Возвращает 201 Created, если ресурс был создан заново. 200 должно быть возвращено, если страницу необходимо обновить, чтобы отразить обновленный ресурс.

301 Moved Permanently

Постоянный редирект. Указывает, что запрошенный ресурс был перемещен на URL-адрес, указанный в заголовке Location, который является фиксированным и не изменится. Поисковая система внесет исправления на основе этого ответа.

Хотя стандарт требует, чтобы браузер не модифицировал метод и тело http при получении ответа и перенаправлении, у некоторых браузеров могут возникнуть проблемы. Поэтому лучше использовать 301 при работе с методами GET или HEAD и использовать 308 вместо 301 в других случаях.

302 Found

Временная переадресация. Код состояния перенаправления указывает, что запрошенный ресурс был временно перемещен на URL-адрес, указанный в заголовке Location. Браузер перенаправит на этот URL, но поисковик не обновит ссылку на ресурс.

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

303 можно использовать в сценариях, где действительно необходимо преобразовать метод перенаправленного запроса в GET. Например, при использовании метода PUT для операций загрузки файлов вам необходимо вернуть информацию подтверждения (например, «вы успешно загрузили xyz») вместо самого загруженного ресурса, вы можете использовать этот код состояния.

303 See Other

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

304 Not Modified

Указывает, что запрошенный контент не нужно передавать повторно, то есть можно использовать кэшированный контент. Обычно это в каком-то безопасном методе (безопасном), таком как GET или HEAD, или в запросе с информацией заголовка: If-None-Match или If-Modified-Since.

Если возвращается 200, ответ будет иметь заголовки Cache-Control, Content-Location, Date, ETag, Expires и Vary.

Last-Modified и If-Modified-Since

  1. Клиент запрашивает файл (A). Сервер возвращает файл A и возвращает Last-Modified.
  2. После того, как клиент получит ответ, он кэширует файл A и Last-Modified.
  3. Когда клиент снова запрашивает файл a снова, найдите файл последнего модифицированного, затем заголовок, содержащий if-модифицированный - поскольку на этот раз кэширует файлы последним модифицированным.
  4. Когда сервер получает запрос, ему нужно только оценить это время и время модификации запрошенного в данный момент файла, чтобы определить, следует ли возвращать 304 или 200.

Основным недостатком If-Modified-Since является то, что он может быть точным только на уровне секунд.Если за одну секунду происходит несколько модификаций, невозможно судить об измененном состоянии. Поэтому он обычно используется для статических ресурсов, которые не очень чувствительны ко времени.

ETag и If-None-Match

  1. Клиент запрашивает файл (A). Сервер возвращает файл A и добавляет к нему ETag.
  2. После того, как клиент получит ответ, он кэширует файл вместе с ETag.
  3. Когда клиент снова запрашивает файл A, он отправляет If-None-Match, содержимое которого кэширует значение Etag файла A.
  4. Сервер сравнивает ETag с рассчитанным Etag, чтобы определить, не был ли файл изменен. Возвращает 304 и пустое тело, если не изменено. В противном случае вернуть 200 и файл.

При использовании с IF-модифицированным - с тех пор, если--None-match принимает приоритет (если сервер поддерживает его)

307 Temporary Redirect

Временная переадресация. Подобно 302, разница заключается в том, что метод запроса и тело сообщения не изменятся.

308 Permanent Redirect

Постоянный редирект. Подобно 301, разница заключается в том, что метод запроса и тело сообщения не изменятся.

400 Bad Request

Указывает, что запрос не может быть понят сервером из-за недопустимого синтаксиса. Клиент НЕ ДОЛЖЕН повторять этот запрос без изменений.

401 Unauthorized

Описание Отправленный запрос не был выполнен из-за отсутствия учетных данных для проверки подлинности, требуемых целевым ресурсом.

Этот код состояния отправляется с заголовком WWW-Authenticate, который содержит информацию о том, как пройти аутентификацию.

WWW-аутентификация и авторизация

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

WWW-Authenticate: <type> realm=<realm> 
  • type : Authentication type. A common type is "Basic".
  • realm= : A description of the protected area. If no realm is specified, clients often display a formatted hostname instead.

пример:

WWW-Authenticate: Basic

WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"

Заголовок запроса на авторизацию содержит учетные данные, которые сервер использует для аутентификации пользовательского агента, и обычно отправляется в последующих запросах после того, как сервер вернет код состояния 401 Unauthorized и заголовок WWW-Authenticate. грамматика:

Authorization: <type> <credentials>
  • type : Authentication type. A common type is "Basic".
  • credentials :
    1. The username and the password are combined with a colon (aladdin:opensesame).
    2. The resulting string is base64 encoded (YWxhZGRpbjpvcGVuc2VzYW1l).

403 Forbidden

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

404 Not Found

Указывает, что сервер не может найти запрошенный ресурс. Ссылки, которые возвращают этот ответ, часто называют неработающими или мертвыми ссылками, и они приводят к обработке ошибок ссылок.

404 не указывает, временно или навсегда потерян запрошенный ресурс. Если сервер знает, что ресурс безвозвратно потерян, он должен вернуть 410 (Gone) вместо 404.

405 Method Not Allowed

Указывает, что сервер запрещает запросы с использованием текущего метода HTTP. Следует отметить, что методы GET и HEAD не должны быть запрещены и, конечно же, не должны возвращать код состояния 405.

406 Not Acceptable

Указывает, что сервер не поддерживает то, что требуют заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Language.

Принять и Content-Type

Accept используется для информирования клиента о типе содержимого, которое может быть обработано клиентом.MIMEтип для представления. Сервер выбирает один из них для применения и информирует об этом клиента, используя заголовок ответа Content-Type.

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Multiple types, weighted with the quality value syntax:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
  • <MIME_type>/<MIME_subtype> : A single, precise MIME type, like text/html.
  • <MIME_type>/* : A MIME type, but without any subtype. image/* will match image/png, image/svg, image/gif and any other image types.
  • / : Any MIME type
  • ;q= (q-factor weighting)

Accept-Encoding и Content-Encoding

Accept-Encoding информирует клиента о том, как закодировано содержимое (обычно это какой-то алгоритм сжатия), понятный клиенту. Сервер выберет один для использования и уведомит клиента в заголовке Content-Encoding ответного сообщения.

Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

Content-Encoding: gzip

409 Conflict

Указывает, что запрос конфликтует с текущим состоянием целевого ресурса на стороне сервера.

Конфликты чаще всего возникают в ответах на запросы PUT. Например, можно получить ответ 409, когда версия загруженного файла старше, чем уже существующая на сервере, что приводит к конфликту версий.

410 Gone

Это указывает на то, что запрошенный контент больше не существует на сервере и безвозвратно утерян. Если неясно, является ли потеря постоянной или временной, следует использовать 404.

413 Payload Too Large

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

Если «превышенный предел» является временным, серверу СЛЕДУЕТ возвращать поле заголовка Retry-After, указывающее, что это временное значение, и через какое время клиент может повторить попытку.

412 Precondition Failed

Указывает на ошибку клиента, означающую, что запрос на доступ к целевому ресурсу был отклонен. Обычно это происходит, когда условные запросы выполняются с помощью методов, отличных от GET и HEAD, где предварительные условия, указанные в полях заголовка If-Unmodified-Since или If-None-Match, не выполняются.

414 URI Too Long

Указывает, что клиент запросил URI за пределами диапазона, разрешенного сервером.

431 Request Header Fields Too Large

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

Этот код ответа может использоваться, когда общий размер заголовка слишком большой, или когда один заголовок слишком велик.

500 Internal Server Error

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

Например: ошибка синтаксиса кода; рабочая память php-кода превышает лимит памяти memory_limit; ошибка конфигурации конфигурации nginx;

501 Not Implemented

Указывает, что метод или Content-* в заголовке запроса не поддерживается сервером и не может быть обработан. Кроме того, единственными методами, которые должен поддерживать сервер (то есть методами, которые не возвращают этот код состояния), являются GET и HEAD. Ответы 501 кэшируются по умолчанию.

502 Bad Gateway

Указывает, что сервер действует как шлюз или прокси, а ответ, полученный от вышестоящего сервера (например, tomcat, php-fpm), недействителен.

Пример: зависает php-fpm

503 Service Unavailable

Указывает, что сервер еще не находится в состоянии, позволяющем принимать запросы. Обычно причиной этого является то, что сервер отключен на техническое обслуживание или перегружен. Этот тип ответа СЛЕДУЕТ использовать во временных ситуациях и, где это применимо, СЛЕДУЕТ включать ожидаемое время восстановления службы в поле заголовка Retry-After.

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

Retry-After

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

  • When sent with a 503 response, this indicates how long the service is expected to be unavailable.
  • When sent with a 429 response, this indicates how long to wait before making a new request.
  • When sent with a redirect response, such as 301, this indicates the minimum time that the user agent is asked to wait before issuing the redirected request.

грамматика:

Retry-After: <http-date>
Retry-After: <delay-seconds>
  • : A date after which to retry.
  • : A non-negative decimal integer indicating the seconds to delay after the response is received.

пример:

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

504 Gateway Timeout

Указывает, что шлюз или прокси-сервер не смог получить желаемый ответ в течение указанного времени.

Например: истекло время выполнения кода или бесконечный цикл.

проблема

500 и 503 соответственно представляют что и в какой ситуации будет использоваться.

Разница между 401 и 403

  1. 401 Unauthorized используется для потерянной или неправильной аутентификации, заголовок ответа содержит www-Authenticate для описания того, как пройти аутентификацию, обычно возвращается веб-сервером, а не приложением, это временно, сервер попросит повторить попытку
  2. 403 Forbidden означает, что проверка подлинности прошла, но нет разрешения на запрошенную операцию с ресурсом, что является постоянным и связано с логикой приложения.

Ссылка из