Http error codes wiki

From Wikipedia, the free encyclopedia

This is a list of Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The optional message phrases shown are typical, but any human-readable alternative may be provided, or none at all.

Unless otherwise stated, the status code is part of the HTTP standard (RFC 9110).

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes.^[1]

All HTTP response status codes are separated into five classes or categories. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. There are five classes defined by the standard:

• 1xx informational response – the request was received, continuing process
• 2xx successful – the request was successfully received, understood, and accepted
• 3xx redirection – further action needs to be taken in order to complete the request
• 4xx client error – the request contains bad syntax or cannot be fulfilled
• 5xx server error – the server failed to fulfil an apparently valid request

1xx informational response

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not^{[note 1]} send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.

100 Continue

The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]

101 Switching Protocols

The requester has asked the server to switch protocols and the server has agreed to do so.

102 Processing (WebDAV; RFC 2518)

A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.

103 Early Hints (RFC 8297)

Used to return some response headers before final HTTP message.^[4]

2xx success

This class of status codes indicates the action requested by the client was received, understood, and accepted.^[1]

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled, resulting in the creation of a new resource.^[5]

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

203 Non-Authoritative Information (since HTTP/1.1)

The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6][7]

204 No Content

The server successfully processed the request, and is not returning any content.

205 Reset Content

The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.

206 Partial Content

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-Status (WebDAV; RFC 4918)

The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]

208 Already Reported (WebDAV; RFC 5842)

The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.

226 IM Used (RFC 3229)

The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[9]

3xx redirection

This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.^[1]

A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. A user agent should detect and intervene to prevent cyclical redirects.^[10]

300 Multiple Choices

Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found (Previously «Moved temporarily»)

Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.

304 Not Modified

Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

305 Use Proxy (since HTTP/1.1)

The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.

306 Switch Proxy

No longer used. Originally meant «Subsequent requests should use the specified proxy.»

307 Temporary Redirect (since HTTP/1.1)

In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.

308 Permanent Redirect

This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

This class of status code is intended for situations in which the error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.

400 Bad Request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.

Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]

403 Forbidden

The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.

404 Not Found

The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed

A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.

406 Not Acceptable

The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.

407 Proxy Authentication Required

The client must first authenticate itself with the proxy.

408 Request Timeout

The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»

409 Conflict

Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.

410 Gone

Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.

411 Length Required

The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed

The server does not meet one of the preconditions that the requester put on the request header fields.

413 Payload Too Large

The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]

414 URI Too Long

The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]

415 Unsupported Media Type

The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

416 Range Not Satisfiable

The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]

417 Expectation Failed

The server cannot meet the requirements of the Expect request-header field.^[21]

418 I’m a teapot (RFC 2324, RFC 7168)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23][24][25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26][27]

421 Misdirected Request

The request was directed at a server that is not able to produce a response (for example because of connection reuse).

422 Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.^[8]

423 Locked (WebDAV; RFC 4918)

The resource that is being accessed is locked.^[8]

424 Failed Dependency (WebDAV; RFC 4918)

The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]

425 Too Early (RFC 8470)

Indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.

428 Precondition Required (RFC 6585)

The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.^[28]

429 Too Many Requests (RFC 6585)

The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]

431 Request Header Fields Too Large (RFC 6585)

The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]

451 Unavailable For Legal Reasons (RFC 7725)

A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP version used in the request.

506 Variant Also Negotiates (RFC 2295)

Transparent content negotiation for the request results in a circular reference.^[31]

507 Insufficient Storage (WebDAV; RFC 4918)

The server is unable to store the representation needed to complete the request.^[8]

508 Loop Detected (WebDAV; RFC 5842)

The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).

510 Not Extended (RFC 2774)

Further extensions to the request are required for the server to fulfill it.^[32]

511 Network Authentication Required (RFC 6585)

The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.

420 Method Failure (Spring Framework)

A deprecated response used by the Spring Framework when a method has failed.^[33]

420 Enhance Your Calm (Twitter)

Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}

430 Request Header Fields Too Large (Shopify)

Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]

450 Blocked by Windows Parental Controls (Microsoft)

The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]

498 Invalid Token (Esri)

Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]

499 Token Required (Esri)

Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]

509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)

The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]

529 Site is overloaded

Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]

530 Site is frozen

Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]

598 (Informal convention) Network read timeout error

Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]

599 Network Connect Timeout Error

An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

Microsoft’s Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client’s request.

440 Login Time-out

The client’s session has expired and must log in again.^[42]

449 Retry With

The server cannot honour the request because the user has not provided the required information.^[43]

451 Redirect

Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

IIS sometimes uses additional decimal sub-codes for more specific information,^[46] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.

nginx

The nginx web server software expands the 4xx error space to signal issues with the client’s request.^[47][48]

444 No Response

Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.

494 Request header too large

Client sent too large request or too long header line.

495 SSL Certificate Error

An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.

496 SSL Certificate Required

An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.

497 HTTP Request Sent to HTTPS Port

An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.

499 Client Closed Request

Used when the client has closed the request before the server could send a response.

Cloudflare

Cloudflare’s reverse proxy service expands the 5xx series of errors space to signal issues with the origin server.^[50]

520 Web Server Returned an Unknown Error

The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]

521 Web Server Is Down

The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.

522 Connection Timed Out

Cloudflare timed out contacting the origin server.

523 Origin Is Unreachable

Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.

524 A Timeout Occurred

Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.

525 SSL Handshake Failed

Cloudflare could not negotiate a SSL/TLS handshake with the origin server.

526 Invalid SSL Certificate

Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.

527 Railgun Error

Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]

530

Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

Amazon’s Elastic Load Balancing adds a few custom return codes

460

Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]

463

The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]

561 Unauthorized

An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the «Warning» HTTP header.^[56][57]

Since this «Warning» header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111.^[58]

110 Response is Stale

The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).

111 Revalidation Failed

The cache was unable to validate the response, due to an inability to reach the origin server.

112 Disconnected Operation

The cache is intentionally disconnected from the rest of the network.

113 Heuristic Expiration

The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.

199 Miscellaneous Warning

Arbitrary, non-specific warning. The warning text may be logged or presented to the user.

214 Transformation Applied

Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

• Custom error pages
• List of FTP server return codes
• List of HTTP header fields
• List of SMTP server return codes
• Common Log Format

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry

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

• 201 Created.
• 401 Unauthorized.
• 507 Insufficient Storage.

Клиент узнаёт по коду ответа о результатах своего запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With. Также упоминается пояснительная фраза «Reply With»^[1] в спецификации по WebDAV в Microsoft Developer Network, введённый Microsoft, и 509 Bandwidth Limit Exceeded, введённый в cPanel.

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

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

Обзорный список

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

• 1xx: Informational (информационные):
  • 100 Continue («продолжай»)^[2][3];
  • 101 Switching Protocols («переключение протоколов»)^[2][3];
  • 102 Processing («идёт обработка»);
  • 103 Early Hints («ранняя метаинформация»);
• 2xx: Success (успешно):
  • 200 OK («хорошо»)^[2][3];
  • 201 Created («создано»)^[2][3][4];
  • 202 Accepted («принято»)^[2][3];
  • 203 Non-Authoritative Information («информация не авторитетна»)^[2][3];
  • 204 No Content («нет содержимого»)^[2][3];
  • 205 Reset Content («сбросить содержимое»)^[2][3];
  • 206 Partial Content («частичное содержимое»)^[2][3];
  • 207 Multi-Status («многостатусный»)^[5];
  • 208 Already Reported («уже сообщалось»)^[6];
  • 226 IM Used («использовано IM»).
• 3xx: Redirection (перенаправление):
  • 300 Multiple Choices («множество выборов»)^[2][7];
  • 301 Moved Permanently («перемещено навсегда»)^[2][7];
  • 302 Moved Temporarily («перемещено временно»)^[2][7], 302 Found («найдено»)^[7];;
  • 303 See Other («смотреть другое»)^[2][7];
  • 304 Not Modified («не изменялось»)^[2][7];
  • 305 Use Proxy («использовать прокси»)^[2][7];
  • 306 — зарезервировано (код использовался только в ранних спецификациях)^[7];
  • 307 Temporary Redirect («временное перенаправление»)^[7];
  • 308 Permanent Redirect («постоянное перенаправление»)^[8].
• 4xx: Client Error (ошибка клиента):
  • 400 Bad Request («неправильный, некорректный запрос»)^[2][3][4];
  • 401 Unauthorized («не авторизован (не представился)»)^[2][3];
  • 402 Payment Required («необходима оплата»)^[2][3];
  • 403 Forbidden («запрещено (не уполномочен)»)^[2][3];
  • 404 Not Found («не найдено»)^[2][3];
  • 405 Method Not Allowed («метод не поддерживается»)^[2][3];
  • 406 Not Acceptable («неприемлемо»)^[2][3];
  • 407 Proxy Authentication Required («необходима аутентификация прокси»)^[2][3];
  • 408 Request Timeout («истекло время ожидания»)^[2][3];
  • 409 Conflict («конфликт»)^[2][3][4];
  • 410 Gone («удалён»)^[2][3];
  • 411 Length Required («необходима длина»)^[2][3];
  • 412 Precondition Failed («условие ложно»)^[2][3][9];
  • 413 Payload Too Large («полезная нагрузка слишком велика»)^[2][3];
  • 414 URI Too Long («URI слишком длинный»)^[2][3];
  • 415 Unsupported Media Type («неподдерживаемый тип данных»)^[2][3];
  • 416 Range Not Satisfiable («диапазон не достижим»)^[3];
  • 417 Expectation Failed («ожидание не удалось»)^[3];
  • 418 I’m a teapot («я — чайник»);
  • 419 Authentication Timeout (not in RFC 2616) («обычно ошибка проверки CSRF»);
  • 421 Misdirected Request ^[10];
  • 422 Unprocessable Entity («необрабатываемый экземпляр»);
  • 423 Locked («заблокировано»);
  • 424 Failed Dependency («невыполненная зависимость»);
  • 425 Too Early («слишком рано»);
  • 426 Upgrade Required («необходимо обновление»);
  • 428 Precondition Required («необходимо предусловие»)^[11];
  • 429 Too Many Requests («слишком много запросов»)^[11];
  • 431 Request Header Fields Too Large («поля заголовка запроса слишком большие»)^[11];
  • 449 Retry With («повторить с»)^[1];
  • 451 Unavailable For Legal Reasons («недоступно по юридическим причинам»)^[12].
  • 499 Client Closed Request (клиент закрыл соединение);
• 5xx: Server Error (ошибка сервера):
  • 500 Internal Server Error («внутренняя ошибка сервера»)^[2][3];
  • 501 Not Implemented («не реализовано»)^[2][3];
  • 502 Bad Gateway («плохой, ошибочный шлюз»)^[2][3];
  • 503 Service Unavailable («сервис недоступен»)^[2][3];
  • 504 Gateway Timeout («шлюз не отвечает»)^[2][3];
  • 505 HTTP Version Not Supported («версия HTTP не поддерживается»)^[2][3];
  • 506 Variant Also Negotiates («вариант тоже проводит согласование»)^[13];
  • 507 Insufficient Storage («переполнение хранилища»);
  • 508 Loop Detected («обнаружено бесконечное перенаправление»)^[14];
  • 509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала»);
  • 510 Not Extended («не расширено»);
  • 511 Network Authentication Required («требуется сетевая аутентификация»)^[11];
  • 520 Unknown Error («неизвестная ошибка»)^[15];
  • 521 Web Server Is Down («веб-сервер не работает»)^[15];
  • 522 Connection Timed Out («соединение не отвечает»)^[15];
  • 523 Origin Is Unreachable («источник недоступен»)^[15];
  • 524 A Timeout Occurred («время ожидания истекло»)^[15];
  • 525 SSL Handshake Failed («квитирование SSL не удалось»)^[15];
  • 526 Invalid SSL Certificate («недействительный сертификат SSL»)^[15].

Описание кодов

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

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

• 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
• 101 Switching Protocols — сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade. Сервер отправляет заголовок ответа Upgrade, указывая протокол, на который он переключился. Появился в HTTP/1.1.
• 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.
• 103 Early Hints — используется для раннего возврата части заголовков, когда заголовки полного ответа не могут быть быстро сформированы.

Успех

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

• 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.
• 208 Already Reported — члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова.
• 226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

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

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT)^[17]. Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

Статус ответа	Кэширование	Если метод не GET или HEAD
301 Moved Permanently	Можно как обычно.	Спросить у пользователя подтверждения и запросить другой ресурс исходным методом.
307 Temporary Redirect	Можно только если указан заголовок Cache-Control или Expires.
302 Found (HTTP/1.1) 302 Moved Temporarily (HTTP/1.0)
303 See Other	Нельзя.	Перейти автоматически, но уже методом GET.

• 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
• 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
• 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому 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). Согласно ранним наброскам, код означал Switch Proxy, указывая клиенту сменить используемый прокси-сервер на указанный сервером в заголовке ответа^[18].
• 307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303-м вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).
• 308 Permanent Redirect — запрашиваемый ресурс был окончательно перенесен на новый URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST-запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместо 301-го для избежания неоднозначности. Введено в RFC 7238 (RFC 7538).

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

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

• 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
• 401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Иными словами, для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization с требуемыми для аутентификации данными. Если запрос уже включает данные для авторизации, ответ 401 означает, что в авторизации с ними отказано.
• 402 Payment Required — предполагается использовать в будущем^{[когда?]}. В настоящий момент^{[когда?]} не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

• 403 Forbidden^[19] — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Иными словами, клиент не уполномочен совершать операции с запрошенным ресурсом. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401, или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае серверу следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
• 404 Not Found^[20] — самая распространённая ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URL. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 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, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа (например копии). Появился в 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 Payload Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1. Ранее назывался «Request Entity Too Large».
• 414 URI Too Long — сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1. Ранее назывался «Request-URI Too Long».
• 415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
• 416 Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges^{[источник не указан 3971 день]}. Введено в RFC 2616 (обновление HTTP/1.1). Ранее назывался «Requested Range Not Satisfiable».
• 417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
• 418 I’m a teapot — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами^[21].
• 419 Authentication Timeout (not in RFC 2616) — Этого кода нет в RFC 2616, используется в качестве альтернативы коду 401, которые прошли проверку подлинности, но лишены доступа к определённым ресурсам сервера. Обычно код отдается, если CSRF-токен устарел или оказался некорректным.
• 421 Misdirected Request — запрос был перенаправлен на сервер, не способный дать ответ.
• 422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис), однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
• 423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
• 424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
• 425 Too Early — сервер не готов принять риски обработки «ранней информации». Введено в RFC 8470 для защиты от атак повторения при использовании 0-RTT в TLS 1.3.
• 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.
• 449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент^{[когда?]} используется как минимум программой Microsoft Money.
• 451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google^[12], при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту». Был добавлен в стандарт 21 декабря 2015 года^[22].
• 499 Client Closed Request — нестандартный код, предложенный и используемый nginx для случаев, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

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

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

• 500 Internal Server Error^[23] — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в 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/1.1.
• 506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
• 507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
• 508 Loop Detected — операция отменена, т.к. сервер обнаружил бесконечный цикл при обработке запроса без ограничения глубины. Введено в WebDAV.
  • 508 Resource Limit Reached — вариант ошибки 508 в CloudLinux, возникающий при исчерпании лимитов хостинга^[24].
• 509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
• 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
• 511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.
• 520 Unknown Error, возникает когда сервер CDN не смог обработать ошибку веб-сервера; нестандартный код CloudFlare.
• 521 Web Server Is Down, возникает когда подключения CDN отклоняются веб-сервером; нестандартный код CloudFlare.
• 522 Connection Timed Out, возникает когда CDN не удалось подключиться к веб-серверу; нестандартный код CloudFlare.
• 523 Origin Is Unreachable, возникает когда веб-сервер недостижим; нестандартный код CloudFlare.
• 524 A Timeout Occurred, возникает при истечении тайм-аута подключения между сервером CDN и веб-сервером; нестандартный код CloudFlare.
• 525 SSL Handshake Failed, возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером; нестандартный код CloudFlare.
• 526 Invalid SSL Certificate, возникает когда не удаётся подтвердить сертификат шифрования веб-сервера; нестандартный код CloudFlare.

См. также

• Список заголовков HTTP
• Код ответа

Примечания

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации)

• Hypertext Transfer Protocol (HTTP) Status Code Registry (англ.). IANA (17 октября 2007). — реестр кодов состояния HTTP. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
• RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с англ. — «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (UC Irvine  (англ.) (рус.), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), Frystyk Henrik  (англ.) (рус. (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)  — обновление протокола HTTP версии 1.1.
• RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (с англ. — «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (UC Irvine  (англ.) (рус.), Gettys Jim (DEC), Mogul J. (DEC), Frystyk Henrik  (англ.) (рус. (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
• RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0» (англ.) (с англ. — «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (UC Irvine  (англ.) (рус.), Frystyk Henrik  (англ.) (рус. (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации)

• RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)» (англ.) (с англ. — «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WebDAV)»); IETF, июнь 2007; Dusseault Ed. L. (CommerceNet  (англ.) (рус.) — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
• RFC 3229 Proposed standard «Delta encoding in HTTP» (англ.) (с англ. — «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken  (англ.) (рус.), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
• RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1» (англ.) (с англ. — «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; Khare Rohit  (англ.) (рус. (4K Associates/UC Irvine  (англ.) (рус.), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
• RFC 2774 Experimental «An HTTP Extension Framework» (англ.) (с англ. — «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
• Internet Draft «WebDAV Advanced Collections Protocol» (с англ. — «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (UC Irvine  (англ.) (рус.), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (FileNet  (англ.) (рус.), Crawford J. (IBM), Chihaya T. (DataChannel)  — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
• RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV» (англ.) (с англ. — «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (UC Irvine  (англ.) (рус.), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
• RFC 2295 Experimental «Transparent Content Negotiation in HTTP» (англ.) (с англ. — «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).

Дополнительные материалы

• Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions (англ.). Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Дата обращения: 30 июля 2009. Архивировано 17 февраля 2012 года.
• RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)» (англ.) (с англ. — «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
• KB 318380 Коды состояния служб IIS. Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Дата обращения: 16 января 2010. Архивировано 17 февраля 2012 года.
• Справочник по кодам статуса HTTP. Яндекс. — обработка кодов состояния HTTP роботами Яндекса. Дата обращения: 2 мая 2018.

Эта страница в последний раз была отредактирована 28 ноября 2022 в 05:11.

Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.

Информационные 100 Continue «Продолжить». Этот промежуточный ответ указывает, что запрос успешно
принят и клиент может продолжать присылать запросы либо проигнорировать
этот ответ, если запрос был завершён. Только HTTP/1.1 101 Switching Protocol «Переключение протокола». Этот код присылается в ответ на запрос
клиента, содержащий заголовок Upgrade:, и указывает, что
сервер переключился на протокол, который был указан в заголовке. Эта
возможность позволяет перейти на несовместимую версию протокола и обычно
не используется. Только HTTP/1.1 102 Processing «В обработке». Этот код указывает, что сервер получил запрос и
обрабатывает его, но обработка ещё не завершена. Только HTTP/1.1 103 Early Hints «Ранние подсказки». В ответе сообщаются ресурсы, которые могут быть
загружены заранее, пока сервер будет подготавливать основной ответ.
RFC 8297 (Experimental). Только HTTP/1.1 Успешные 200

OK

«Успешно». Запрос успешно обработан. Что значит «успешно», зависит от
метода HTTP, который был запрошен:

• GET: «ПОЛУЧИТЬ». Запрошенный ресурс был найден и передан в теле
  ответа.
• HEAD: «ЗАГОЛОВОК». Заголовки переданы в ответе.
• POST: «ПОСЫЛКА». Ресурс, описывающий результат действия сервера на
  запрос, передан в теле ответа.
• TRACE: «ОТСЛЕЖИВАТЬ». Тело ответа содержит тело запроса полученного
  сервером.

HTTP/0.9 и выше 201 Created «Создано». Запрос успешно выполнен и в результате был создан ресурс.
Этот код обычно присылается в ответ на запрос PUT «ПОМЕСТИТЬ». HTTP/0.9 и выше 202 Accepted «Принято». Запрос принят, но ещё не обработан. Не поддерживаемо, т.е.,
нет способа с помощью HTTP отправить асинхронный ответ позже, который
будет показывать итог обработки запроса. Это предназначено для случаев,
когда запрос обрабатывается другим процессом или сервером, либо для
пакетной обработки. HTTP/0.9 и выше 203 Non-Authoritative Information «Информация не авторитетна». Этот код ответа означает, что информация,
которая возвращена, была предоставлена не от исходного сервера, а из
какого-нибудь другого источника. Во всех остальных ситуациях более
предпочтителен код ответа 200 OK. HTTP/0.9 и 1.1 204 No Content «Нет содержимого». Нет содержимого для ответа на запрос, но заголовки
ответа, которые могут быть полезны, присылаются. Клиент может
использовать их для обновления кешированных заголовков полученных ранее
для этого ресурса. HTTP/0.9 и выше 205 Reset Content «Сбросить содержимое». Этот код присылается, когда запрос обработан,
чтобы сообщить клиенту, что необходимо сбросить отображение документа,
который прислал этот запрос. Только HTTP/1.1 206 Partial Content «Частичное содержимое». Этот код ответа используется, когда клиент
присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в
несколько потоков. Только HTTP/1.1 Сообщения о перенаправлениях 300 Multiple Choice

«Множественный выбор». Этот код ответа присылается, когда запрос имеет
более чем один из возможных ответов. И User-agent или пользователь
должен выбрать один из ответов. Не существует стандартизированного
способа выбора одного из полученных ответов.

HTTP/1.0 и выше 301 Moved Permanently

«Перемещён на постоянной основе». Этот код ответа значит, что URI
запрашиваемого ресурса был изменён. Возможно, новый URI будет
предоставлен в ответе.

HTTP/0.9 и выше 302 Found

«Найдено». Этот код ответа значит, что запрошенный ресурс
временно изменён. Новые изменения в URI могут быть доступны в
будущем. Таким образом, этот URI, должен быть использован клиентом в
будущих запросах.

HTTP/0.9 и выше 303 See Other «Просмотр других ресурсов». Этот код ответа присылается, чтобы
направлять клиента для получения запрашиваемого ресурса в другой URI с
запросом GET. HTTP/0.9 и 1.1 304 Not Modified «Не модифицировано». Используется для кеширования. Это код ответа
значит, что запрошенный ресурс не был изменён. Таким образом, клиент
может продолжать использовать кешированную версию ответа. HTTP/0.9 и выше 305 Use Proxy «Использовать прокси». Это означает, что запрошенный ресурс должен быть
доступен через прокси. Этот код ответа в основном не поддерживается из
соображений безопасности. Только HTTP/1.1 306 Switch Proxy Больше не использовать. Изначально подразумевалось, что » последующие
запросы должны использовать указанный прокси.» Только HTTP/1.1 307 Temporary Redirect «Временное перенаправление». Сервер отправил этот ответ, чтобы клиент
получил запрошенный ресурс на другой URL-адрес с тем же методом, который
использовал предыдущий запрос. Данный код имеет ту же семантику, что код
ответа 302 Found, за исключением того, что агент
пользователя не должен изменять используемый метод HTTP: если в первом
запросе использовался POST, то во втором запросе также
должен использоваться POST. Только HTTP/1.1 308 Permanent Redirect

«Перенаправление на постоянной основе». Это означает, что ресурс
теперь постоянно находится в другом URI, указанном в заголовке
Location: HTTP Response. Данный код ответа имеет ту же
семантику, что и код ответа 301 Moved Permanently, за
исключением того, что агент пользователя не должен изменять
используемый метод HTTP: если POST использовался в первом
запросе, POST должен использоваться и во втором запросе.

Примечание: Это экспериментальный код ответа,
Спецификация которого в настоящее время находится в черновом виде.

draft-reschke-http-status-308 Клиентские 400 Bad Request «Плохой запрос». Этот ответ означает, что сервер не понимает запрос
из-за неверного синтаксиса. HTTP/0.9 и выше 401 Unauthorized «Неавторизованно». Для получения запрашиваемого ответа нужна
аутентификация. Статус похож на статус 403, но,в этом случае,
аутентификация возможна. HTTP/0.9 и выше 402 Payment Required «Необходима оплата». Этот код ответа зарезервирован для будущего
использования. Первоначальная цель для создания этого кода была в
использовании его для цифровых платёжных систем(на данный момент не
используется). HTTP/0.9 и 1.1 403 Forbidden «Запрещено». У клиента нет прав доступа к содержимому, поэтому сервер
отказывается дать надлежащий ответ. HTTP/0.9 и выше 404 Not Found «Не найден». Сервер не может найти запрашиваемый ресурс. Код этого
ответа, наверно, самый известный из-за частоты его появления в вебе. HTTP/0.9 и выше 405 Method Not Allowed «Метод не разрешён». Сервер знает о запрашиваемом методе, но он был
деактивирован и не может быть использован. Два обязательных метода,
GET и HEAD, никогда не должны быть
деактивированы и не должны возвращать этот код ошибки. Только HTTP/1.1 406 Not Acceptable

Этот ответ отсылается, когда веб сервер после выполнения
server-driven content negotiation, не нашёл контента, отвечающего критериям, полученным из user agent.

Только HTTP/1.1 407 Proxy Authentication Required Этот код ответа аналогичен коду 401, только аутентификация требуется для
прокси сервера. Только HTTP/1.1 408 Request Timeout Ответ с таким кодом может прийти, даже без предшествующего запроса. Он
означает, что сервер хотел бы отключить это неиспользуемое соединение.
Этот метод используется все чаще с тех пор, как некоторые браузеры,
вроде Chrome и IE9, стали использовать
HTTP механизмы предварительного соединения
для ускорения сёрфинга (смотрите баг 634278, будущей
реализации этого механизма в Firefox). Также учитывайте, что некоторые
серверы прерывают соединения не отправляя подобных сообщений. Только HTTP/1.1 409 Conflict

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

Только HTTP/1.1 410 Gone

Этот ответ отсылается, когда запрашиваемый контент удалён с сервера.

Только HTTP/1.1 411 Length Required

Запрос отклонён, потому что сервер требует указание заголовка
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 Long URI запрашиваемый клиентом слишком длинный для того, чтобы сервер смог
его обработать Только HTTP/1.1 415 Unsupported Media Type Медиа формат запрашиваемых данных не поддерживается сервером, поэтому
запрос отклонён Только HTTP/1.1 416 Requested Range Not Satisfiable Диапазон указанный заголовком запроса Range не может быть
выполнен; возможно, он выходит за пределы переданного URI Только HTTP/1.1 417 Expectation Failed Этот код ответа означает, что ожидание, полученное из заголовка запроса
Expect, не может быть выполнено сервером. Только HTTP/1.1 Серверные 500 Internal Server Error «Внутренняя ошибка сервера». Сервер столкнулся с ситуацией, которую он
не знает как обработать. HTTP/0.9 и выше 501 Not Implemented «Не реализовано». Метод запроса не поддерживается сервером и не может быть
обработан. Единственные методы, которые сервера должны поддерживать (и,
соответственно, не должны возвращать этот код) — GET и
HEAD. HTTP/0.9 и выше 502 Bad Gateway «Плохой шлюз». Эта ошибка означает что сервер, во время работы в
качестве шлюза для получения ответа, нужного для обработки запроса,
получил недействительный (недопустимый) ответ. HTTP/0.9 и выше 503 Service Unavailable «Сервис недоступен». Сервер не готов обрабатывать запрос. Зачастую
причинами являются отключение сервера или то, что он перегружен.
Обратите внимание, что вместе с этим ответом удобная для
пользователей(user-friendly) страница должна отправлять объяснение
проблемы. Этот ответ должен использоваться для временных условий и
Retry-After: HTTP-заголовок должен, если возможно,
содержать предполагаемое время до восстановления сервиса. Веб-мастер
также должен позаботиться о заголовках, связанных с кешем, которые
отправляются вместе с этим ответом, так как эти ответы, связанные с
временными условиями, обычно не должны кешироваться. HTTP/0.9 и выше 504 Gateway Timeout Этот ответ об ошибке предоставляется, когда сервер действует как шлюз и
не может получить ответ вовремя. Только HTTP/1.1 505 HTTP Version Not Supported «HTTP-версия не поддерживается». HTTP-версия, используемая в запросе, не
поддерживается сервером. Только HTTP/1.1

A status code is a part of the response returned by the server when a client (e.g., a browser) calls a URL. With the help of a status code, the server tells the client whether the request was successfully processed or whether an error occurred.

Status classes

The three-digit HTTP status codes can be classified in different status classes, where the first digit stands for the respective status class.

• HTTP status codes of the first class represent information for processing and are sent during the request, they include status code 100 and status code 102.
• HTTP status codes of the second class represent a successful operation. One of the most common HTTP status codes that begins with a 2 is status code 200 OK.
• A status code of the third class represents a redirection and is returned if the requested document is now available at a different address. Processing is, therefore, not yet complete and requires further actions by the client. Some of the most important status codes in this class with respect to search engine optimization are status code 301 and status code 302.
• HTTP status codes of the fourth class represent client errors, i.e. errors that results from a faulty request by the client. A good example in this class is status code 404 Not Found.
• The fifth class contains server errors. These are errors that are attributed to the server. status code 500 Internal Server Error and status code 503 Service Unavailable are good examples in this class.
• The ninth status class covers both the standardized status codes as well as proprietary codes that may occur under certain circumstances. Here, the error is attributed to the network, and the client is required to resend the request. Most common in this class are status code 906 and status code 950.

Check HTTP status codes

Normally, the web browser does not show the status code. Therefore, you have to use special tools to monitor these. Browser extensions are a good way of monitoring HTTP status codes such as using
Live Http-Headers or using special online tools like Web-Sniffer.

Status code 1xx — information

Status code 100

Status code 100 is returned if the server has correctly received a request and is now waiting for further instructions from the client. Only then can the request be executed by the server.

Status code 102

This processing status code is used to prevent a timeout during the request. This can happen especially if the server has to process a time-consuming request.

Status code 2xx – successful operation

Status code 200

Status code 200 is returned by the server if the data requested by the client (e.g., web browser) were transmitted as desired. Here, the following requirements usually have to be met:

• The server must accept the client’s request, and
• the requested resource must exist on the server.
• In addition, the server must be in a position to send the resource to the client.

If these requirements are met, the requested data are sent to the client and the status code 200 OK is included in the response.

Status code 200 is one of the most commonly occurring status codes as it represents the normal case. The status code is returned when there are no problems.

Status code 3xx — redirection

Status code 301

Status code 301 shows that the resource requested by the client is no longer available at the given address but has rather been permanently moved to another address (redirect). The old address of the resource is henceforth no longer valid. The new address is sent back to the requesting client, enabling the client to retrieve the resource at the new address.

The difference between status code 301 and the very similar status code 302 lies in the time designation. While the old address remains valid if status code 302 is returned, the old address is no longer valid if status code 301 is returned. The 301 redirect thereby inherits the link juice, whereas this is not the case with 302.

Use case – URL change

In the best case scenario, a once assigned URL structure remains unchanged forever. However, if it becomes necessary to change the URL structure of a page or to change its domain, it must be ensured that all the old URLs are redirected to the new URL. This particularly applies to URLs that have acquired valuable external links over time. This is done using a 301 redirect. In this case, if the no longer existing URL is called, the server returns the status code 301 and informs the client of the new URL of the resource. According to the RFC standard, an absolute URL should be used in a redirect. Thus, relative redirects are not valid.

Using 301

There are different ways of sending status code 301. For example, when using PHP-based applications, a corresponding header can be generated. To do this, the following PHP code must be added in the old file:

<!--?phpHeader( "HTTP/1.1 301 Moved Permanently" );
Header( "Location: http://www.new-url.com" );
?-->

It is, however, much more practicable to send the status code 301 using the .htaccess file. This requires a Linux server with an activated Apache mod-rewrite|Mod-Rewrite Module. The following lines must be added in the .htaccess file:

Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^domain.com [nc]
rewriterule ^(.*)$ http://www.domain.com/$1 [r=301,nc]

When using the status code 301, it should be ensured that all pages are redirected 1:1 to the new subpages and not to the homepage in case of a domain change. Furthermore, the so-called routing loops or long routing chains should be avoided. Googlebot usually switches off after the fourth or fifth redirection.

Redirection of links

A 301 redirect redirects most of the link juice to the new destination but not the reputation of the page on Google Plus (social signals). Before moving the content, one should first check whether the redirection is really desirable.

Status code 302

Status code 302 Found shows a temporary redirect. This means that the requested resource can temporarily be found at another address. In addition to this status code, the server also returns the new address of the resource. One important difference to Status Code 301 is that the original address remains valid. This is also the reason why contents that are permanently accessible at a new address should be delivered with status code 301 and not status code 302. This is because Googlebot continues to search through and index the original location during the temporary redirection. It is also important to ensure that no link juice is inherited with status code 302 but rather with status code 301.

Status code 400|Status code 4xx – client error

Status code 404

Status code 404 Not Found is always returned when the requested resource (mostly a URL but can also be an image or other file) does not exist or no longer exists, and is, together with the Status Code 200 “OK” and the 304 “Not Modified”, one of the most common HTTP status codes.

Reasons for the 404 status code

A non-existent resource can arise if:

• The resource was moved to a different location, but not all internal links were altered accordingly.
• The resource was moved to a different location, there were also external references to the document and in addition to the internal links. These were, however, not informed of the move and are, therefore, still linked to the old address. These are usually known as “dead links”.
• The client has requested for a resource that never existed such as by modifying or tampering with an existing, valid URL in the address bar of the browser. This often occurs with copied links.

Rectifying the 404 error

It should always be ensured that the number of 404 errors is kept as low as possible. This is because neither users nor Googlebot are happy when they encounter an error page. One can use Google Search Console under “Status -> Crawl error” to regularly view the pages found by Google with status code 404. All the information about the internal and external links of the URL can also be viewed here. This makes it possible to detect and modify the important linked 404 pages.

Soft 404 errors

Soft 404 errors are encountered in websites that no longer provide the requested content nor return the 404 or 410 status code. In such cases, the webmaster has not provided any 404 error page, so that status codes “200 Ok” or “302 Found” are issued when visiting the pages.

In practice, there is little point when users search for specific content but are shown a page that does not show any error code and instead displays content that does not match the query. Google itself recommends the use of the 404 status code when the content is no longer hosted on a page.^[1] For better usability, the error page can be optimized to persuade the users to stay on the website.

Common SEO tools, Google Search Console, or the Bing Webmaster tools can be used to analyze soft 404 errors.

Status code 5xx – server error

Status code 500

Status code 500 shows internal server errors. The requested resource can, therefore, not be transmitted due to a server error. Since this is basically a “generic HTTP status code” for all possible unexpected server errors, it is not that descriptive. However, status code 500 is mostly returned in the case of incorrect entries in the .htaccess file.

Status code 503

Status code 503 shows a temporary unavailability of the server. This can be as a result of several reasons. For example, this status code can be shown during maintenance or overload of the server. A “retry after” header field can be added to inform the client of the corresponding time when the sent request can be processed. It should hereby be noted that with status code 503, the server does not process the request even after the respective capacities are available again.

Status code 9xx – proprietary status codes

Status code 906

This status code is provided if an error occurs during transmission of the request from the client to the remote server. The request must be sent again.

Status code 950

Status code 950 is returned if an error occurs in the interpretation of an administrative request of the client. Here as well, the request must be sent again in most cases.

Significance of status codes for search engine optimization

The http status codes play an important role in search engine optimization. A high frequency of 404 errors can indicate a badly maintained website. If users receive the status code 404 when they access URLs, this leads to a higher bounce rate, which in turn represents a negative user signal for Google and other search engines.

The indication «404-not found» is a natural part of the web, if a page is no longer available, for example due to a domain transfer. Soft 404 errors, on the other hand, have a greater effect on search engine optimization. You deliver a status code that does not match the content of the page. In the worst case, Soft 404 errors can lead to the exclusion of a URL from the Google index.

Also important for the SEO are 301 redirects because they help prevent duplicate content.

References

Web Links

• Description of HTTP status codes
• 60 really cool and creative error 404 pages

Every time a task is run on a monitored device, the target server returns HTTP status codes to indicate the status of the response from the server.

These HTTP status codes, or network error codes, will appear in the results of a monitoring session as well as in alert notifications.  These status codes are maintained by the Internet Assigned Numbers Authority (IANA) and the most current list of codes can be found here.

Using Filters you can remove results with specific status codes from your tasks, alerts, and reports.  Click on the RFC reference documents in the list below for full details of the status codes.

What is the HTTP Protocol? 

Every time a user visits a website, they are making a request from their browser/client to a server that responds with the resources they requested. These requests all follow the HTTP (Hypertext Transfer Protocol) standard. The HTTP protocol, which is technically part of the application layer within the Internet Protocol suite, is just one many protocols under the IP suite. The HTTP protocol is the backbone of the Internet used for communication and sending data between clients and servers. Some of the other more common Internet protocols you many have come across include the following: 

Application Layer Protocols 

The application later specifies the protocols and interface methods used by clients and servers. It is the layer where the interaction between person and computer occurs and information can be sent back and forth from a server via a client/browser and interpreted and displayed for users. 

• DNS: The DNS (Domain Name System) protocol converts domain names to human-readable IP addresses for browser so resources can be loaded.  
• FTP: The FTP (File Transfer Protocol) protocol is used to transfer files between a browser and a server within a computer network. 
• SMTP: The SMTP (Simple Mail Transfer Protocol) protocol is used to send and receive emails between senders and receivers on a network. 
• TLS/SSL: The SSL (Secure Sockets Layer) protocol was officially deprecated in 2015. TLS (Transport Layer Security) was introduced in its place to provide a secure way to communicate over a network. 
• IMAP: The IMAP (Internet Message Access Protocol) protocol is used to manage and receive messages from an email server. Unlike SMTP, you cannot use the IMAP protocol to send email messages.  
• POP: The POP (Post Office Protocol) protocol is like IMAP, but the difference is that the POP protocol allows the user to receive messages from an email server, but the message is then deleted from the email server. The IMAP protocol can sync messages across multiple devices. It really depends on how you want users to access their emails. 
• SIP: The SIP (Session Initiation Protocol) protocol is a signaling protocol that is used in real-time voice, video, and messaging applications. SIP is the protocol that is used to enable and deploy VoIP (Voice Over Internet Protocol) services. SIP is also used in conjunction with other protocols, such as SDP (Session Description Protocol), UDP, TCP, and TLS to carry session data and media. 

Transport Layer Protocols 

The transport layer handles the transmission of data, which also includes the TCP and UDP protocols, and ensuring data is sent and received correctly and promptly. 

• TCP: The TCP (Transport Control Protocol) protocol is used to ensure transmissions between a client and server are secure and that the entire communication was processed. For example, when a server sends back a file due to a client request, the HTTP layer will communicate with the transport layer to set up and send the file requested. The TCP protocol manages the process of assembling and sending (and sometimes re-sending, if necessary) the data packets and ensures that all packets have been send and delivered. 
• UDP: The UDP (User Datagram Protocol) protocol allows applications to send messages, called datagrams, to other hosts on a network.  

Internet Layer Protocols 

The internet layer, also called the network layer, is tasked with sending and reassembling network packets in the most efficient way using network addresses/IP address to send packets to their destination. 

• IP: The IP (Internet Protocol) protocol, along with the TCP protocol, is a set of requirements that define how data is sent over the Internet.  
• ICMP: ICMP (Internet Control Message Protocol) protocol is a network protocol that allows network devices, like routers, to help diagnose communication issues. The ICMP protocol is not concerned with exchanging data, rather its purpose is to ensure whether the data is reaching the intended destination. 

Link Layer Protocols 

The link layer is the group of communication methods that manages the transmission of data between physical devices and a network.

• ARP: The ARP (Address Resolution Protocol) protocol/procedure for mapping IP network addresses to an address of a physical hardware device, otherwise known as a MAC address.  
• MAC: The MAC (Medium Access Control) protocol gives hardware devices their unique identification number. It provides a way for the networks to connect and communicate with devices. 
• Wi-Fi: The Wi-Fi (Wireless Fidelity) protocol, which is one of the protocols that all of us rely on for everyday life, is a group of wireless network protocols that is used for connecting to the Internet access and LANs (Local Area Networks). 

What are Status Codes and Why are They Important? 

There are even extensions of the HTTP protocol, which includes HTTPS (Hypertext Transfer Protocol Secure) and WebDAV (Web-based Distributed Authoring and Versioning), which we will discuss more within the HTTP status codes below. When a client makes a request to the server, status codes let you know if the request was successful, failed, or something different. Status codes are maintained by the Internet Assigned Numbers Authority, or IANA, and includes status codes from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC). As defined by the IANA organization, there are five classifications of HTTP status codes:

1xx: Informational – Request received, continuing process
2xx: Success – The action was successfully received, understood, and accepted
3xx: Redirection – Further action must be taken in order to complete the request
4xx: Client Error – The request contains bad syntax or cannot be fulfilled
5xx: Server Error – The server failed to fulfill an apparently valid request

Individuals and engineers regularly propose new status codes through Requests for Comments (RFC), and the IETF will review, adopt, and retire status codes as necessary.

HTTP Status Codes Explained 

The information below provides an overview of all the most common HTTP status codes, as well as the HTTP status codes that most folks rarely never see or even know exist. Like we mentioned, a lot of response codes are never seen by users, as they are viewable only within the network. 

The first digit of the status code identifies the class; however, the second two digits do not play any role in further defining the status code to a specific type of message/response. Within these classification groups, there can be multiple status codes, and some groups have more status codes than others. And while there are officially over 60 unique status codes, most people will regularly only encounter a handful or two over time.  

Most of these status codes are interpreted and processed behind the scenes. You will also see that there are groups of codes that are labeled as “Unassigned.” While most of the status codes that we see today have been standardized and have not changed over time, these unassigned numbers leave room for creating additional status codes as necessary. Additionally, even though some of the unassigned user codes are not formerly part of the HTTP (Hypertext Transfer Protocol) standard, there are companies that use them as customized server response for users, allowing companies to better troubleshoot issues users may be experiencing. Click on the RFC reference document links in the list below for full details of the specific HTTP status code. 

A Complete List and Overview of HTTP Status Codes

1xx Status Codes:  Informational 

The 1xx-level HTTP status codes tell users that the request that they have made has been received but is still processing. The 1xx status codes do not necessarily mean there is an issue, it is just there to let you something is still in the process of completing. Included in this group are just a handful of 1xx codes that users may come across and need to be aware of. 

100: Continue

Status code 100 Continue tells you that a part of the request has been received without any problems. At this point everything is OK but is still in process. If the remaining part of the request is not rejected, the server will send a final response once the request has been completed. If the HTTP headers had been rejected, this ensures that the client does not send a request for the body. However, if the request did not contain a header field, then the browser will simply ignore the response. See RFC7231, Section 6.2.1 for more information. 

101: Switching Protocols

There have been many HTTP protocols created since the Internet’s humble beginnings. The first documented version of the HTTP protocol was HTTP 0.9. The current iteration is HTTP 2.0 or HTTP/2. Status code 101 Switching Protocols indicates that the server accepts the request from the client to switch to a different HTTP protocol through the Upgrade header field. When a browser makes a request for a page, it might receive the HTTP status code 101 and then the Upgrade header, which indicates the sever is switching to a different HTTP version. Finally, the assumption is that the server will agree to switch protocols only when it is beneficial, like upgrading/switching to a newer protocol versus an older one. See RFC7231, Section 6.2.2 for more information.  

102: Processing

A status code 102 Processing is only used with WebDAV (Web Distributed Authoring and Versioning). Most pages are read-only. WebDAV is an extension of the HTTP protocol that gives clients the ability to edit content remotely and transfer files. The WebDAV protocol was created to give users the ability to collaborate on files with others, like Dropbox or Google Drive. Status code 102 is an interim response code, telling the client that the server has accepted the full request, but has not completed the request. This HTTP status code is only sent by the server if a request is taking longer than 20 seconds. See RFC2518, Section 10.2 for more information.  

103: Early Hints

Status codes 103 Early Hints is currently in the evaluation/experimental phase. This status code would be used when preloading external content/resources. The HTTP/2 protocol allows content to be pushed to accelerate delivery, so web developers could push specific content while waiting for other external resources to load. This is beneficial from the end user’s perspective as it minimizes the perceived load time. This HTTP response code would indicate to a browser that the server is going to send a final response, along with the header fields included in the response. See RFC8297, Section 2 for more information

104-199: Unassigned

Status codes 104 through 199 are currently unassigned.

2xx Status Code: Success 

The 2xx-level HTTP status codes indicate that the client’s request from the server was successfully received and processed. Unlike 4xx status codes, 2xx status codes are what you want to get. Like 1xx status codes, the 2xx status codes are processed behind the scenes and rarely seen by users, unless they are using developer or SEO tools to see all the HTTP responses of a page. 

200: OK

One of the mostly widely used HTTP status codes, status code 200 OK is used to indicate that a request was received, processed, and was successful. However, depending on the request method used (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). For example, if the request is a GET request, the response will include the resource. If it is any of the other requests, the response will include the result of the actions. The 200 status code is one of more than 10 other response codes that is also cacheable, meaning that it can be saved and retrieved via the client, so as not to have to make another request to the server in the future. See RFC7231, Section 6.3.1 for more information. 

201: Created

A 201 Created status code is like a 200 OK status code, however, a 201 status code means that a request was successfully processed, and it returned, or created, a resource or resources in the process. A 201 status code is typically used for PUT requests. For example, when a PUT request is used, a new resource is created on the URL specified in the request. If there is a 201 status code in a POST request, it means a resource was created at a different API endpoint/location. See RFC7231, Section 6.3.2  for more information. 

202: Accepted

The 202 Accepted status code means that the server has received a request for processing, and it is been accepted, but the request has not been completed. It also does not mean the request will eventually be accepted, as it will depend on when the actual processing takes place. This type of request is typically seen in APIs where a batch process is run once a day. Since there is no way for HTTP to communicate after a request has succeeded or user’s connection has been closed, an API might send off an email to a user notifying them that the process has succeeded. See RFC7231, Section 6.3.3 for more information. 

203: Non-Authoritative Information

The 203 Non-Authoritative Information status code is typically used by an HTTP proxy or third party. The proxy, sitting between the client and server may change the responses before reaching the client. To indicate that something was changed during the process, a status code 203 is used. However, the drawback of this method is that it is not possible to know what the original status code was if a proxy changed something in the response. A suggested workaround is to use a warning header along with a 214 status code, which is used to indicate that there was a change or modification in the response. Using the warning header allows the original status code to passed through. See RFC7231, Section 6.3.4 for more information. 

204: No Content

A status code of 204 No Content indicates that the response has been successfully delivered by the server and fulfilled and no further content is to be sent in the body of the response. As an example, if the request is sent in the form on a page, once the response is sent, the client/browser is not supposed to change the view, meaning the form should not be refreshed or direct users to a new page. No additional content should be replaced or appear in terms of the user’s perspective. See RFC7231, Section 6.3.5 for more information.  

205: Reset Content 

Like the 204 No Content status code, a status code 205 Reset Content indicates that the server has sent the request successfully and requires the user agent to refresh/reset the view to its original state. If we use the example of a form on a page, once the user completes and submits the form, the client/browser should clear the form back to its original state so a user can take further action. A 205 status code assumes no further content will be provided. See RFC7231, Section 6.3.6 for more information. 

206: Partial Content

A 206 Partial Content status code can be used for a variety of requests and typically indicates that the server has fulfilled a partial request for a resource. For example, if a client is only looking for a specific portion, or range, of a specific resource or page. Another example of where a 206 status code is used is in video. A client may only load video in pieces as to not have to wait for the video to buffer or load, helping to avoid a negative user experience where a user would have to wait longer before the video plays. This is normal best practice among HTTP video players to avoid bandwidth and perceived latency issues. See RFC7233, Section 4.1 for more information.  

207: Multi-Status

The 207 Multi-Status status code provides status for multiple independent processes and used by WebDAV servers. The default message/response is a text/XML message. It indicates that multiple operations have taken place and that the status for each operation can be viewed in the body of the response. Status codes could vary between any one of the five categories. Response codes will vary depending on the number of sub-requests. Unlike other 200 status codes, a 207 status code does not confirm that the process was successful. The client needs to view the body of each request to determine if it was successful or not. See RFC4918, Section 11.1 for more information. 

208: Already Reported 

The 208 Already Reported status code is another status code used within the WebDAV extension. Like the 207 status code, it allows a client/browser to indicate to the server that a resource was already processed. When a client asks for resources, it can be possible that a response includes duplicate resources, which would mean the same resources would be sent multiple times, which is redundant. The 208 status response avoids the possibility of processing and repeating the same response. 208 status code responses will only appear in the body of response and never as an actual HTTP response. See RFC5842, Section 7.1 for more information. 

209-225: Unassigned 

Status codes 209 through 225 are currently unassigned. 

226: IM Used

A 226 IM (Instance Manipulations) Used status code is used to indicate that a server has completed a GET request for a resource, but the response is representation of one or several instance manipulations that have been applied to the current instance. Within the HTTP protocol there is an extension called Delta encoding in HTTP that is supported on the server-side. If this is implemented, the client can request changes to the cached version, and the server will send the changes instead of re-sending the entire resource again. To be able to implement this feature, the client/browser request needs to specify what IM type supported. If the server supports this feature as well, it will respond with the 226 status code and the changes. If a 200 status code is sent back, that indicates the feature is not supported. See RFC3229, Section 10.4.1 for more information.  

227-299: Unassigned

Status codes 227 through 299 are currently unassigned. 

3xx: Redirection 

The 3xx status codes are used in cases of URL redirection. Websites are always changing and evolving, so there may be times where marketers need to direct users to an updated, or different page. Redirects help alleviate users from having to search for what they are looking for and maintain your ranking in search engines. The redirect actions may be carried out by the browser automatically or may require additional interaction from users. The 3xx HTTP status codes are vital for SEO (Search Engine Optimization) and user experience, as well as tell search engines what content you want them to crawl and index. If not properly implemented, users may be directed to an unintended location, which could result in a 4xx status code and could affect SEO quality scores.

300: Multiple Choices

The 300 Multiple Choices status code indicates that a resource has moved and can redirect to multiple locations. In this case the user must decide which resource to use. The server may indicate a preferred choice and that should be indicated in the header field where the user agent could redirect to the preferred choice automatically. In practical use, this status code is rarely used as there is no standardized way to choose from multiple responses. See RFC7231, Section 6.4.1 for more information. 

301: Moved Permanently

A 301 Moved Permanently status code is utilized to indicate that a target resource has been moved to a permanent location. The 301 status code tells the browser/client to use this new location or URL going forward in the header. Along with the 301 status code, the new URL will be given in the response as well as update any URLs in the previous location(s), along with updating to the new URL. See RFC7231, Section 6.4.2 for more information. 

302: Found

A 302 Found status code indicates to a client/browser that a resource that they are accessing is temporarily located under a different location. Unlike the 301 status code, a 302 status code indicates a temporary move, so the client should not automatically update its links to the new location, as again, it is meant to be temporary. An example of where the 302 status code should be used if there are multiple URLs, but they could be served in different languages. A user may arrive at specific URL, but the client may redirect them automatically to the proper page based on their browser settings and use this on subsequent visits. It is noted that in some cases, browsers may change a request from POST to GET. In the case that this action is not favorable, a 307 status code should be used. See RFC7231, Section 6.4.3 for more information.  

303: See Other

A status code 303 See Other indicates that a server will be redirecting the client/browser to another resource. The resource will be indicated as a URL the header field. Unlike the 301 and 302 status codes, it does not mean a resource has temporarily or permanently move, its intent is to specify the URL to where the response to the specific request can be found via a GET request. 303 status codes should not be cached, however, the response to the subsequent request may be cached. A typical use of the 303 status code would be to ensure users do not accidentally resubmit form data via a POST request. They should be directed to a new page. If not, they may unknowingly click the back button in their browser, which may ask them to resubmit again, which leads to unnecessary duplicate submissions. See RFC7231, Section 6.4.4 for more information.  

304: Not Modified

A status code of 304 Not Modified is sent in response to a conditional GET or HEAD request. Clients/browsers can send a conditional request, such as If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, or If-Range, asking if a specific resource has been modified since a specific date/time. This is done only if the client has previously accessed, downloaded, and saved the resource. If it has been modified since that specific date/time last accessed, the server will return a 200 OK status code. If it has not been changed since that date/time, the 304 status code is sent as the response, indicating that the saved resource should be served since it has not been modified since the last time it was accessed. See RFC7232, Section 4.1 for more information. 

305: Use Proxy

The 305 Use Proxy status code is a deprecated status code that is no longer used due to security consideration. It was used to indicate to a client that the resource they were accessing must be accessed via a proxy. For more information on the 305 Use Proxy status code, see RFC7231, Section 6.4.5 

306: Unused

Like the 305 status code, the 306 Unused status was originally known as Switch Proxy. The 306 status code was used in a previous specification. Its intention was to be used as in indication to the client that subsequent requests to a resource should use the proxy that was specified. This was deemed as a security issue, so it is no longer used. For more information on the 306 Unused status code, see RFC7231, Section 6.4.6  

307: Temporary Redirect 

Like the 302 Found redirect status code, the 307 Temporary Redirect status code indicates to the client/browser that a resource or document is available at a different, temporary URL and returns that URL. Since the redirection is temporary and could change, the browser/client should continue to access the current URL for subsequent requests. The main difference between the 302 status code and the 307 status code is that the 307 status code does not allow changing requests from a POST request to a GET request, so if the client requested POST request, it be redirected and initiate the POST request again. See RFC7231, Section 6.4.7  

308: Permanent Redirect 

A 308 Permanent Redirect status code is a cacheable status code (unless cache controls are implemented) that indicates that a target resource is now located at a permanent URL and subsequent requests should be directed to that URL as well. Additionally, the client should update any old bookmarks to the new location. The 308 status code is very similar to the 301 status code, however, if a 308 status code is sent, the client has to initiate and send the same request on the target location. A 301 status code does not have to do this. Most browsers/clients change the POST request to a GET request. See RFC7238, Section 3 for more information.  

309-399: Unassigned

Status codes 309 through 399 are currently unassigned. 

4xx: Client Error 

The classification with the most HTTP status codes, 4xx HTTP status codes are not what you want your users to see. Any status code that begins with a 4 means there is an issue with the client. 4xx status codes are usually generated if a page has been deleted and not redirected, or something incorrectly entered within a URL or link. If users get a dreaded 4xx status code, that means there is a problem with the client/browser receiving information from the server. These are errors that users will see pop up on their screen and create a negative user experience, leading to a bit of frustration and them looking somewhere else. If search engines crawl your site and receive a 404 error, for example, this will show up as an error in the report. A few 404 errors are fine and search engines do not necessarily view these as a negative thing, but a 404 that redirects to a 404 could negatively impact your SEO. Not only that, if the page in question is used to drive traffic or sales, this could lead to loss in potential revenue. 

400: Bad Request

A 400 Bad Request error status code means that the server cannot process the request due to an issue from the client. This could be due to any number of reasons, such as a file being too large, bad syntax, an invalid URL, or some other issue caused by a third-party application, which is why the 400 status code is sometimes uses as a catch all status code, even if there is an issue on the server-side. This can make troubleshooting a 400 status code a bit more time consuming and difficult, however, along with the 400 status code error and header information, the server can provide additional response along with it, which can be displayed to the user to help identify the issue and ease the process of troubleshooting and diagnosing the error. See RFC7231, Section 6.5.1 for more information. 

401: Unauthorized

A 401 Unauthorized error status code indicates that the request does not include the appropriate authentication credentials, authentication has failed, or the user must log in. The client requires authentication from the server. The terms authorized and authenticated are often use interchangeably, but they mean separate things. A status code of 401 is strictly concerned with authentication. In cases where you would want to inform a client that they are not allowed at all, then a status code of 403 should be implemented. According to the specification, the 401 status code must also include the WWW-Authenticate header from the server response, indicating to the client what authentication scheme or method the server requires. See RFC7235, Section 3.1 for more information.  

402: Payment Required 

Originally created as part of a way to allow for potential future digital payment methods, the 402 Payment Required error status code is officially reserved for future use, but it used some limited, but rare, situations. For more information on the 402 Payment Required error code, see RFC7231, Section 6.5.2   

403: Forbidden

The 403 Forbidden error status code indicates that the request from the client was understood, but the server will not authorize it, so the client cannot access it. The server can make known the reason it will not authorize the request within the response, which could be due to various reasons like incorrect password or username. Unlike the 401 status code, which require authentication, a 403 status code can indicate that the client truly does not have authorization to access those resources, so authentication in this instance is not possible. See RFC7231, Section 6.5.3 for more information. 

404: Not Found

One of the most common and infamous status codes encountered by users and developers, the 404 Not Found error status code indicates that the resource required from the server does not exist or is not willing to provide it to the client. A 404 status code will not indicate whether the lack of providing the resource is temporarily or permanently, but the client can make subsequent requests to access it. In cases where its known that the resources are permanently gone, the 410 status code should be used. 404 status codes, by default, are also cacheable, unless other cache controls are in place. See RFC7231, Section 6.5.4 for more information. 

405: Method Not Allowed

The 405 Method Not Allowed error status code indicates that a specific resource requested by the client is not supported by the server. The 405 Method Not Allowed is like the 403 Forbidden status code, however, the 403 status code indicates that the resource may be available, it is just that the client does not have the necessary authorization to carry out the request. Along with the 405 Method Not Allowed status, the server must indicate the appropriate and supported methods for the target resource. For more information on the 405 Method Not Allowed error code, see RFC7231, Section 6.5.5  

406: Not Acceptable

Like the 405 Method Not Allowed error status code, the 406 Not Acceptable error code indicates that there is not support for a specific request. In this case the 406 Not Acceptable status code indicates that the server understood the request, but the response is not supported or understood by the client. A client can request specific versions of a resource in the header, such as A-IM or Accept Language, among others, but if the server does not support it, it responds with the 406 Not Acceptable status code. The server can either respond with a list of appropriate resource identifiers that the client can choose from. See RFC7231, Section 6.5.6 for more information.  

407: Proxy Authentication Required

The 407 Proxy Authentication Required error status code is like the 401 Unauthorized status code, however, in the case of a 407 status code, in order to use a proxy, the client must first be authenticated. The proxy must return the method for authentication. Not as common today due to the rise of VPNs, proxies act as intermediaries between users/clients and the Internet, allowing users to access resources more quickly, as content is typically cached, and can also provide a layer of security and anonymity for users. For more information on the 407 Proxy Authentication Required error code, see RFC7235, Section 3.2  

408: Request Timeout

A 408 Request Timeout error status code means that the server did not receive a request from the client in a specified amount of time. A delayed request from the client can be due for a variety of reasons, such as a slow or broken connection. Once that time has passed, the 408 Request Timeout status is sent by the server and the user/client can resend the request again. For more information on the 408 Request Timeout error code, see RFC7231, Section 6.5.7 

409: Conflict

A 409 Conflict error status code indicates that the request from the client could not be processed due to a conflict with the server. The request from the client was fine, but there were issues on the server-side that prevents the request from being executed. An example of this could be if there was a request for a specific file to be edited, deleted, or created by the user, but those functionalities are not allowed. Along with the 409 response, the server should return instructions on how the user can resolve this issue or indicate why the issue is occurring. See RFC7231, Section 6.5.8 for more information. 

410: Gone

Like the 404 Not Found error status code we covered earlier, the 410 Gone status code indicates that the resource the client is requesting has been removed and no longer available from the server. No further information is provided in terms of URL redirection or where to access the resource. It has been removed indefinitely. For more information on the 410 Gone error code, see RFC7231, Section 6.5.9  

411: Length Required

The 411 Length Required error status code indicates that the server does not allow the request from the client due to a predefined request body content length. The request can be repeated by the client if a valid Content-Length header is specified in the subsequent resource request. For more information on the 411 Length Required error code, see RFC7231, Section 6.5.10  

412: Precondition Failed

Conditional requests to the server are allowed as part of the HTTP protocol. If the right conditions are met in the request, the request is executed and processed by the server. A 412 Precondition Failed error status code means that one, or several, conditions in the request header has failed. For example, this can be used in GET requests and a conditional request is utilized to return the resource only if that resource has changed. For more information on the 412 Precondition Failed error code, see RFC7232, Section 4.2  

413: Request Entity Too Large

The 413 Request Entity Too Large error status code indicates that the server will not accept and process the request due to the request body being larger than the server will allow or can process. Such examples include uploading a file where the file exceeds the maximum upload size set by the server or when the maximum number of uploads has been exceeded. In cases where the 413 Request Entity Too Large error occurs, the server may close the connection completely to prevent the client from continuing to sending the request. In some cases, it is likely the server would allow the client to retry the request, if itis a temporary condition, and should include that message back to the client. However, it is possible the request could cause the server itself to run out of physical disk space. In this case, the 507 Insufficient Storage error is the response that the client should receive back. See RFC7231, Section 6.5.11 for more information.  

414: URI Too Long

Not a very common server response, the 414 URI Too Long error status code means that the server refused the client request due to the URL being longer than the server can process. Browsers and search engines do put limits on the length of URLs, partly to avoid DDoS attacks or code errors, but the path of a URL or HTTP does not have explicit limits. So, if limit exceeds what is set by the server, the 414 URI Too Long error will occur. For more information on the 414 URI Too Long error code, see RFC7231, Section 6.5.12  

415: Unsupported Media Type

The 415 Unsupported Media Type error status code indicates the server cannot process the request body, or part of the request body, due to an unsupported media format. Even if the request from the client is supported, the 415 error may be returned if there is unsupported content in the body of the request. A 415 Unsupported Media Type error code is like the 406 Not Acceptable status code. The difference is that a 406 Not Acceptable error code is not due to the content in the header or encoding, rather, it is due to the value set within the HTTP header. Ensuring that the server can process the defined format along with sending the request with the correct form will avoid a 415 Unsupported Media Type error status code from happening. See RFC7231, Section 6.5.13 for more information. 

416: Range Not Satisfiable

As mentioned with the 206 Partial Request status code, it is possible for clients/browsers to request a partial response back from the server, whether it is a specific part of a file or video for example. Clients and servers use what is called range requests to execute these requests. However, if the server does not support these types of requests, it will simply return the entire resource along with a 200 OK response. If the server does support range requests, that is where the 416 Partial Request error status code enters the picture and will return what the client is asking for. In a situation where the server does support range requests, but the server does not agree with the request received because it does not fall within the range or possibly beyond the specified range, the 416 Range Not Satisfiable error status code will be returned. See RFC7233, Section 4.4 for more information.  

417: Expectation Failed 

Clients can use an Expect header to indicate that it expects specific behavior from the server. Like described in the 100 Continue status code, clients can check with the server if it will accept a request. If it does, the server will respond with the 100 Continue status code. If not, the 417 Expectation Failed error status code indicates that the server did not understand the Expect header or support it, therefore it cannot process the client request. For more information on the 417 Expectation Failed error code, see RFC7231, Section 6.5.14  

418-420: Unassigned

Error status codes 418-421 are currently unassigned, however, status code 418 I’m a Little Teapot is used in some instances. Created as an April Fool’s joke, it has gained some traction and is sometimes used as a joke or Easter egg and not used for actual everyday purposes. Most browsers ignore it as it is not an official status code. Another one in this category is the 420 Enhance Your Calm error status code that was introduced by Twitter. It is an error code that tells clients that they are being rate limited, which is a restriction on the number of requests they can make within a specified time period. Since 1989, the RFC Editor will publish the more humorous RFCs. Wikipedia has a full rundown of the more humorous April Fool’s RFCs. 

421: Misdirected Request 

Introduced with the HTTP/2 protocol, the 421 Misdirected Request error status code means that the server received a request that was not intended for that specific server and cannot properly respond. This can happen if the DNS (Domain Name System) is set to the wrong IP address. Clients are required to include a Host header in the request. This can also occur with sites that have a single SSL certificate from multiple domains. This can be caused by an issue with the hosting provider and/or specific browser used, so it can require a great deal of work to really understand where the issue lies. If a server knows that a domain is not configured on the request, it will respond with the 421 Misdirected Request error response. See RFC7540, Section 9.1.2 for more information. 

422: Unprocessable Entity

A 422 Unprocessable Entity error status code indicates an issue with the contents of the syntax of a request. The arrangement of the request was understood by the server, but the fields within the request are invalid or does not match what the server expects. Like the 102 Processing and 207 Multi-Status status codes, a 422 Unprocessable Entity error code is part of the WebDAV protocol and often used with web services/APIs. Generally, a 400 Bad Request is the recommend response, but if WebDAV is supported, then the 422 Unprocessable Entity should be used. See RFC4918, Section 11.2 for more information. 

423: Locked

Like the 422 Unprocessable Entity error status code, the 423 Locked error status code is also part of the WebDAV protocol. The 423 Locked status code indicates that a file, resource, or directly, for example, cannot be edited. Its purpose is to avoid multiple users updating a file, resource, etc., simultaneously. These resources can then be unlocked for editing, when necessary. For more information on the 423 Locked error code, see RFC4918, Section 11.3 

424: Failed Dependency 

Another status code supported by the WebDav protocol; the 424 Failed Dependency error status code indicates the request from the client failed due to a dependency on another request that also failed. WebDAV utilizes a method known as PROPPATCH to update certain resource properties. To indicate if a resource was updated successfully or not, WebDAV uses standard HTTP status code responses. Additionally, the 424 Failed Dependency status code is only used in instance where the response in the HTTP body has the 207 Multi-Status response. So, if PROPPATCH is used and resource fails to update, it will send a 4xx status code indicating there is an error updating the resource, the 424 Failed Dependency error code will also be sent along with the other requests that depended on that update being successful but failed. See RFC4918, Section 11.4 for more information. 

425: Too Early

Not a common HTTP status code that is used today, the 425 Too Early error response code is used in situations where an HTTP client is connecting to an HTTPS client. During the process, it may take a long time to establish a connection between the server and client. This process can pose a security issue, so the server will tell the client to retry the request until the secure TLS (Transport Layer Security) connection has been made. In that case, the 425 Too Early status code will be returned. For more information on the 425 Too Early error code, see RFC8470, Section 5.2  

426: Upgrade Required 

The 426 Upgrade Required error status code indicates to the client that it needs to utilize a newer protocol in order to send requests to the server. For example, the client may be using and older version of HTTP, like HTTP/1.0, but the server requires HTTP2.0. The server will not accept the request but will respond back to the client indicating which protocol or protocols are acceptable. Once the client has upgraded to the required protocol(s), the server will accept requests from the client. For more information on the 426 Upgrade Required error code, see RFC7231, Section 6.5.15 

427: Unassigned

Error status code 427 is currently unassigned. 

428: Precondition Required 

The 428 Precondition Required error status code indicates to the client that the request to the server must be a conditional request. As mentioned in the 304 Not Modified status code, a client can send a conditional request to the server, such as If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, or If-Range. However, these conditional requests are not required. If they are required by the server, the server indicates this by responding with the 428 Precondition Required error code. This is a bit similar to the 412 Precondition Failed error code, but the 412 Precondition Failed error code is returned only if the client included a conditional request in the header that does not match the state of the resource on the server’s side. By notifying users that requests must be conditional in nature, this ensures users are working with the right files or resources and helps prevent users from potentially overwriting changes. See RFC6585, Section 3 for more information. 

429: Too Many Requests 

Just like the name of the error code indicates, the 429 Too Many Requests error status code means that rate limiting is implemented, and that the client went over the limit for how many requests it can make in a specified amount of time. Along with the 429 Too Many Requests error response, it should be indicated how long to wait before initiating a new request to the server, but it is not formerly required to do so. For more information on the Too Many Requests error code, see RFC6585, Section 4  

430: Unassigned

The 430 error status code is currently unassigned, however, it was at one time proposed to be the 430 Would Block error code within the HTTP/1.1 protocol. The intent was to serve as a response to what is known as pipelining. This allowed clients to send multiple requests, over a TCP connection, while it waited for the server to respond. It never officially made it into the standard as the HTTP protocol was updated to HTTP/2.0 and support for pipelining was never widely adopted.  

431 Request Headers Too Large 

The 431 Request Headers Too Large error status code indicates the client sent a header request that exceed the allowable limit. Different web servers have varying allowable size limits when it comes to headers. This could be due to an individual header request being too large or due to the entire combined size of all the header requests. In most cases, this can be easy to remedy, as it is typically caused by sending too many cookies or cookies that are too large in file size. For more information on the 431 Request Headers Too Large error code, see RFC6585, Section 5   

432-450: Unassigned

Error status codes 432 through 450 are currently unassigned. 

451: Unavailable Due to Legal Reasons 

Error status code 451 Unavailable Due to Legal Reasons indicates the server is refusing to serve up the requested content due to legal reasons and should also include the reason for the error in the response to the user. Reasons for using the 451 Unavailable Due to Legal Reasons error status code could include governments that censor specific content, content that violates copyright laws, like the DMCA (Digital Millennium Copyright Acts), or content that is violates laws or court orders. The 403 Forbidden and 404 Not Found error status codes are sometimes used in place of the 451 error status code, but the 451 error status code provides more information or explanation into why the error is occurring. Users have typically gotten around the 451 error by implementing VPNs to access the content. See RFC7725, Section 3 for more information. 

452-499: Unassigned

Error codes 452-499 are currently unassigned.

5xx: Server Error 

Like the 4xx status codes, the 5xx status codes indicate there is an error, however the error in question is not likely due to a bad connection or the browser itself. 5xx status codes indicate there is an issue at the server level and cannot process the request from the client. Along with the error, the server should respond with an explanation of the error, whether it is a temporary or permanent condition, and how it may be remedied. 

500: Internal Server Error

The 500 Internal Server Error status code simply means that the server encountered an issue and cannot process the request. Typically, the 500 Internal Server Error code used more as a generic server error code if the exact issue does not fall within any of the other 5xx Server Error status code specifications. The 500 Internal Server Error code is probably the most used of the 5xx Server Error classification codes. See RFC7231, Section 6.6 for more information.  

501: Not Implemented

A 501 Not Implemented error status codes occurs when the server does not recognize the method of the request and therefore, cannot support or process the request. It is like the 405 Method Not Allowed client error status code, but a 501 Not Implemented error status code could indicate that the request method from the client is valid, just not supported by the server. The 405 Method Not Allowed error status would indicate that the method called by the client is not supported and should not have been utilized. See RFC7231, Section 6.6.2 for more information.  

502: Bad Gateway

The 502 Bad Gateway error status code means that a server is acting a proxy and it received a response from an origin server that came back as invalid. It is possible it is due to an overloaded server and the client can resubmit the request, but in most cases, it is due to an issue with the web server or CDN (Content Distribution Network) sitting between the client and server and may require additional troubleshooting with the hosting provider to understand why the error is being thrown. See RFC7231, Section 6.6.3 for more information.  

503: Service Unavailable

The 503 Service Unavailable error status code indicates the server is currently overloaded with requests or out of resources, is currently in maintenance, or possibly that the application they are trying to access is down, and the server unable to complete the request due to the current state. Clients will sometimes see a message along with the 503 Service Unavailable error status code telling them to try the request again later. However, it may not provide a definitive explanation of when or how long the 503 Service Unavailable error status code may last. See RFC7231, Section 6.6.4 for information.  

504: Gateway Timeout

Like the 502 Bad Gateway error status code, the 504 Gateway Timeout error status code is used when the server is acting as proxy but will respond with a 504 Gateway Timeout error status code if the response from an origin server takes too long to respond. A 502 Bad Gateway error status code should be used in cases where the response was invalid or not received by the proxy server at all. The message along with the 504 Gateway Timeout may indicate and recommend that the client try resending the request. See RFC7231, Section 6.6.5 for more information. 

505: HTTP Version Not Supported

A 505 HTTP Version Not Supported error status code means that the server does not support the version of the HTTP protocol used in the message of the request, and therefore, cannot process the request. Along with the 505 HTTP Version Not Supported error status code, the response from the server should include a message indicating why that specific HTTP protocol is not supported and which protocols are supported. See RFC7231, Section 6.6.6 for more information.  

506: Variant Also Negotiates

The 506 Variant Also Negotiates is an experimental HTTP status code and is not part of the standard today. A 506 Variant Also Negotiates indicates that there in an internal configuration issue with the server due to content negotiation issues. Content negotiation allows clients to send multiple accept headers and tells the server which specific representation of a resource to serve as indicated by the browser. This could be for serving up the right language, document format, etc. Even though the 506 Variant Also Negotiates error status code is in an experimental status and not officially part of the HTTP standard, is used in rare cases. Some Google Play users encountered this issue in the past when trying to download multiple versions of an application, causing their devices to continually try to download the app in a closed loop process. See RFC2295, Section 8.1 for more information.  

507: Insufficient Storage

A 507 Insufficient Storage server error status code is also part of the WebDAV protocol. The 507 Insufficient Storage error status code indicates to the client that the request, such as a PUT or POST request, was too large in file size. It can also indicate that the server has temporarily run out of storage. See RFC4981, Section 11.5 for more information.  

508: Loop Detected

The 508 Loop Detected server error status code, like the 507 Insufficient Storage server error code, is part of the WebDAV protocol. Within the WebDAV protocol, it is possible the client can make a request to a server for an entire directory and create a target somewhere that same directory, resulting in an infinite request/response loop. The 508 Loop Detected server error status code indicates that the server ended the client request, specifically Depth: Infinity, because the server identified the request as resulting in an infinite loop, repeatedly calling back on itself. See RFC5842, section 7.2 for more information. 

509: Unassigned

The 509 server error status code is currently unassigned. 

510: Not Extended

A 510 Not Extended server error status code is currently in proposed/experimental status and not part of the standard HTTP status code specification. The 510 Not Extended indicates to the client that the request requires an extended HTTP request. If the server responds with the 510 Not Extended server error status code, it should also include how the client should remedy their request, but the specification does not explicitly state that. There’s debate whether this should fall under the 5xx server error classification since it could be viewed as a 4xx client error, but since it is not formally part of the standard, it is not relevant and rarely used for everyday use. See RFC2774, Section 7 for more information.  

511: Network Authorization Required

The 511 Network Authorization Required server error status code that requires the client to authenticate itself in order to gain access to a network. For example, users might see this when trying to connect to a public Wi-Fi network at a business and users must agree to their terms and conditions before being granted access. Along with the 511 Network Authorization Required server error response, users should also be directed to where they can log in. See RFC6585, Section 6 for more information. 

512-599: Unassigned

Server error status codes 512-599 are currently unassigned, but some companies may use any of these as custom server error messages to clients. 

Monitoring HTTP Status Code Responses 

To see a list of status codes for a specific URL firsthand, you can check the developer tools tab within your browser. Along with the page load speed metrics, you can also view any server responses, along with all the associated HTTP status codes, to ensure that everything on your page is loading and rendering properly. 

For a more proactive and automated monitoring approach, the professional monitoring solutions from Dotcom-Monitor can ensure that whenever a specific HTTP error code is encountered by a user, your teams are notified immediately so they can quickly remedy the issue. You can also use the Filters feature to remove individual HTTP status codes from tasks, alerts, and reports, so you disregard any HTTP status codes that are not relevant to your specific needs. 

Содержание

Что такое код ответа HTTP

Как проверить код состояния страницы

В браузере

В Яндекс.Вебмастере

В Google Search Console

1* класс кодов (информационные сообщения)

100 Continue

101 Switching Protocols

102 Processing

103 Checkpoint

105 Name Not Resolved

2* класс кодов (успешно обработанные запросы)

200 ОК

201 Created

202 Accepted

203 Non‑Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi‑Status

226 IM Used

3* класс кодов (перенаправление на другой адрес)

300 Multiple Choices

301 Moved Permanently

302 Found/Moved 

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Resume Incomplete

4* класс кодов (ошибки на стороне клиента)

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request‑URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot

422 Unprocessable Entity

423 Locked

424 Failed Dependency

425 Unordered Collection

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

434 Requested Host Unavailable

444 No Response

449 Retry With

450 Blocked by Windows Parental Controls

451 Unavailable For Legal Reasons

456 Unrecoverable Error

499 Client Closed Request

5* класс кодов (ошибки на стороне сервера)

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

509 Bandwidth Limit Exceeded

510 Not Extended

511 Network Authentication Required

Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

Что такое код ответа HTTP

Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

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

Как проверить код состояния страницы

Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

В браузере

Для примера возьмём Google Chrome.

1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

В Яндекс.Вебмастере

Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

В Google Search Console

Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

А затем в открывшемся окне перейдите на вкладку «Подробнее»:

Теперь расскажем подробнее про все классы кодов состояния HTTP.

1* класс кодов (информационные сообщения)

Это системный класс кодов, который только информирует о процессе передачи запроса. Такие ответы не являются ошибкой, хотя и могут отображаться в браузере как Error Code.

100 Continue

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

101 Switching Protocols

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

102 Processing

Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

103 Checkpoint

Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

105 Name Not Resolved

Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

2* класс кодов (успешно обработанные запросы)

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

200 ОК

Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

201 Created

Создано — транзакция успешна, сформирован новый ресурс или документ.

202 Accepted

Принято — запрос принят, но ещё не обработан.

203 Non‑Authoritative Information

Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).

204 No Content

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

205 Reset Content

Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

206 Partial Content

Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

При работе с подобными ответами следует уделить внимание кэшированию.

207 Multi‑Status

Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

226 IM Used

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

3* класс кодов (перенаправление на другой адрес)

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

300 Multiple Choices

Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

301 Moved Permanently

Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

302 Found/Moved 

Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

303 See Other

Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

304 Not Modified

Модификаций не было — с момента последнего визита клиента изменений не было.

305 Use Proxy

Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

306 Unused

Зарезервировано. Код в настоящий момент не используется.

307 Temporary Redirect

Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

308 Resume Incomplete

Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

4* класс кодов (ошибки на стороне клиента)

Эти коды указывают на ошибки со стороны клиентов. 

400 Bad Request

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

401 Unauthorized

Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.

402 Payment Required

Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

403 Forbidden

Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

404 Not Found

Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

405 Method Not Allowed

Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

406 Not Acceptable

Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

407 Proxy Authentication Required

Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

408 Request Timeout

Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

409 Conflict

Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

410 Gone

Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

411 Length Required

Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

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

412 Precondition Failed

Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

413 Request Entity Too Large

Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 Request‑URI Too Long

Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

415 Unsupported Media Type

Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

416 Requested Range Not Satisfiable

Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

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

417 Expectation Failed

Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

418 I’m a teapot

Первоапрельская шутка разработчиков в 1998 году. В расшифровке звучит как «я не приготовлю вам кофе, потому что я чайник». Не используется в работе.

422 Unprocessable Entity

Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

423 Locked

Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

424 Failed Dependency

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

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

425 Unordered Collection

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

426 Upgrade Required

Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

428 Precondition Required

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

429 Too Many Requests

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

431 Request Header Fields Too Large

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

Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

434 Requested Host Unavailable

Адрес запрашиваемой страницы недоступен.

444 No Response

Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

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

449 Retry With

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

450 Blocked by Windows Parental Controls

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

451 Unavailable For Legal Reasons

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

456 Unrecoverable Error

Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

499 Client Closed Request

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

5* класс кодов (ошибки на стороне сервера)

Эти коды указывают на ошибки со стороны серверов. 

При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.

500 Internal Server Error

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

Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

501 Not Implemented

Не выполнено —  код отдается, когда сам сервер не может идентифицировать метод запроса. 

Сами вы эту ошибку не исправите. Устранить её может только сервер.

502 Bad Gateway

Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

Актуально исключительно для прокси и шлюзовых конфигураций.

503 Service Unavailable

Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). 

В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

504 Gateway Timeout

Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

505 HTTP Version Not Supported

Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

506 Variant Also Negotiates

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

507 Insufficient Storage

Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

508 Loop Detected

Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

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

510 Not Extended

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

511 Network Authentication Required

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

HTTP

Постоянное соединение · Сжатие · HTTPS

Методы

OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH

Заголовки

Cookie · ETag · Location · Referer

DNT · X-Forwarded-For

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

301 Moved permanently

302 Found

303 See Other

403 Forbidden

404 Not Found

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

• 201 Webpage Created.
• 403 Access allowed only for registered users.
• 507 Insufficient Storage.

Клиент узнаёт по коду ответа о результатах его запроса и определяет какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With. Так же упоминается пояснительная фраза «Reply With»^[2] в спецификации по WebDAV в Microsoft Developer Network, введённый Microsoft и 509 Bandwidth Limit Exceeded, введённый в cPanel. Компания Google предложила комитету IETF использовать HTTP-код 451 для уведомления о преднамеренном блокировании порталов^[3].

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

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

Обзорный список

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

• 1xx: Informational (информационные):
  • 100 Continue («продолжить»)^[1][4].
  • 101 Switching Protocols («переключение протоколов»)^[1][4].
  • 102 Processing («идёт обработка»).
• 2xx: Success (успешно):
  • 200 OK («хорошо»)^[1][4].
  • 201 Created («создано»)^[1][4][5].
  • 202 Accepted («принято»)^[1][4].
  • 203 Non-Authoritative Information («информация не авторитетна»)^[1][4].
  • 204 No Content («нет содержимого»)^[1][4].
  • 205 Reset Content («сбросить содержимое»)^[1][4].
  • 206 Partial Content («частичное содержимое»)^[1][4].
  • 207 Multi-Status («многостатусный»)^[6].
  • 226 IM Used («использовано IM»).
• 3xx: Redirection (перенаправление):
  • 300 Multiple Choices («множество выборов»)^[1][7].
  • 301 Moved Permanently («перемещено навсегда»)^[1][7].
  • 302 Moved Temporarily («перемещено временно»)^[1][7].
  • 302 Found («найдено»)^[7].
  • 303 See Other (смотреть другое)^[1][7].
  • 304 Not Modified (не изменялось)^[1][7].
  • 305 Use Proxy («использовать прокси»)^[1][7].
  • 306 — зарезервировано (код использовался только в ранних спецификациях)^[7].
  • 307 Temporary Redirect («временное перенаправление»)^[7].
• 4xx: Client Error (ошибка клиента):
  • 400 Bad Request («плохой, неверный запрос»)^[1][4][5].
  • 401 Unauthorized («неавторизован»)^[1][4].
  • 402 Payment Required («необходима оплата»)^[1][4].
  • 403 Forbidden («запрещено»)^[1][4].
  • 404 Not Found («не найдено»)^[1][4].
  • 405 Method Not Allowed («метод не поддерживается»)^[1][4].
  • 406 Not Acceptable («не приемлемо»)^[1][4].
  • 407 Proxy Authentication Required («необходима аутентификация прокси»)^[1][4].
  • 408 Request Timeout («истекло время ожидания»)^[1][4].
  • 409 Conflict («конфликт»)^[1][4][5].
  • 410 Gone («удалён»)^[1][4].
  • 411 Length Required («необходима длина»)^[1][4].
  • 412 Precondition Failed («условие ложно»)^[1][4][8].
  • 413 Request Entity Too Large («размер запроса слишком велик»)^[1][4].
  • 414 Request-URI Too Large («запрашиваемый URI слишком длинный»)^[1][4].
  • 415 Unsupported Media Type («неподдерживаемый тип данных»)^[1][4].
  • 416 Requested Range Not Satisfiable («запрашиваемый диапазон не достижим»)^[4].
  • 417 Expectation Failed («ожидаемое неприемлемо»)^[4].
  • 422 Unprocessable Entity («необрабатываемый экземпляр»).
  • 423 Locked («заблокировано»).
  • 424 Failed Dependency («невыполненная зависимость»).
  • 425 Unordered Collection («неупорядоченный набор»)^[9].
  • 426 Upgrade Required («необходимо обновление»).
  • 449 Retry With («повторить с»)^[2].
  • 456 Unrecoverable Error («некорректируемая ошибка»).
• 5xx: Server Error (ошибка сервера):
  • 500 Internal Server Error («внутренняя ошибка сервера»)^[1][4].
  • 501 Not Implemented («не реализовано»)^[1][4].
  • 502 Bad Gateway («плохой, ошибочный шлюз»)^[1][4].
  • 503 Service Unavailable («сервис недоступен»)^[1][4].
  • 504 Gateway Timeout («шлюз не отвечает»)^[1][4].
  • 505 HTTP Version Not Supported («версия HTTP не поддерживается»)^[1][4].
  • 506 Variant Also Negotiates («вариант тоже проводит согласование»)^[10]
  • 507 Insufficient Storage («переполнение хранилища»).
  • 508 Loop Detected («обнаружена петля»)^[11]
  • 509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала»).
  • 510 Not Extended («не расширено»).

Описание кодов

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

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

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

Успех

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

• 200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
• 201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется^{[источник не указан 278 дней]} ещё указывать в заголовке характеристики созданного ресурса (например, в поле 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 — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

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

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

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

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT)^[13]. Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

Статус ответа	Кэширование	Если метод не GET или HEAD
301 Moved Permanently	Можно как обычно.	Спросить у пользователя подтверждения и запросить другой ресурс исходным методом.
307 Temporary Redirect	Можно только если указан заголовок Cache-Control или Expires.
302 Found (HTTP/1.1) <nobr>302 Moved Temporarily (HTTP/1.0)</nobr>
303 See Other	Нельзя.	Перейти автоматически, но уже методом GET.

• 300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
• 301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
• 302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому 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 заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

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

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

• 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
• 401 Unauthorized — запрос требует идентификации пользователя. Сервер должен запросить имя и пароль у пользователя, а тот передаст их в заголовке WWW-Authenticate в следующем запросе. Если были указаны неверные данные, то сервер снова вернёт этот же статус. Появился в HTTP/1.0.
• 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. Появился в 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 — возвращается, если ни одно из условных полей заголовка^{[неизвестный термин]} запроса не было выполнено. Появился в HTTP/1.1.
• 413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
• 414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного 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^{[источник не указан 278 дней]}. Введено в RFC 2616 (обновление HTTP/1.1).
• 417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
• 422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
• 423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
• 424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
• 425 Unordered Collection — посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного^{[уточнить]}. Введено в черновике по WebDAV Advanced Collections Protocol^[14].
• 426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
• 449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
• 456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных^{[источник не указан 278 дней]}. Введено корпорацией Microsoft для WebDAV.

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

Коды 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/1.1.
• 506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
• 507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
• 509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
• 510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

См. также

• Список заголовков HTTP

Примечания

Ссылки

	Файлы о коде 404 на Викискладе?

Основные документы по протоколу HTTP (по убыванию даты публикации):

• Hypertext Transfer Protocol (HTTP) Status Code Registry  (англ.). IANA (17 октября 2007). — реестр кодов состояния HTTP. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
• RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (англ.)русск. (UC Irvine (англ.)русск.), Gettys Jim (англ.)русск. (Compaq/W3C), Mogul J. (Compaq), Frystyk Henrik (англ.)русск. (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT)  — обновление протокола HTTP версии 1.1.
• RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (англ.)русск. (UC Irvine (англ.)русск.), Gettys Jim (англ.)русск. (DEC), Mogul J. (DEC), Frystyk Henrik (англ.)русск. (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
• RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (англ.)русск. (UC Irvine (англ.)русск.), Frystyk Henrik (англ.)русск. (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации):

• RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)» (англ.) (русск. «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WEBDAV)»); IETF, июнь 2007; Dusseault Ed. L. (CommerceNet (англ.)русск.) — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
• RFC 3229 Proposed standard «Delta encoding in HTTP» (англ.) (русск. «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken (англ.)русск.), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
• RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1» (англ.) (русск. «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; Khare Rohit (англ.)русск. (4K Associates/UC Irvine (англ.)русск.), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
• RFC 2774 Experimental «An HTTP Extension Framework» (англ.) (русск. «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
• Internet Draft «WebDAV Advanced Collections Protocol» (русск. «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (UC Irvine (англ.)русск.), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (FileNet (англ.)русск.), Crawford J. (IBM), Chihaya T. (DataChannel)  — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
• RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV» (англ.) (русск. «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (UC Irvine (англ.)русск.), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
• RFC 2295 Experimental «Transparent Content Negotiation in HTTP» (англ.) (русск. «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).

Дополнительные материалы:

• Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions  (англ.). Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Архивировано из первоисточника 17 февраля 2012. Проверено 30 июля 2009.
• RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)» (англ.) (русск. «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
• KB 318380 Коды состояния служб IIS  (рус.). Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Архивировано из первоисточника 17 февраля 2012. Проверено 16 января 2010.
• Dean Alan. HTTP/1.1 (DELETE, GET, HEAD, PUT, POST)  (англ.) (23 января 2007). — диаграмма принятия веб-сервером решений об ответе в зависимости от заголовков (схема в формате GIF).(недоступная ссылка — история) Проверено 16 января 2010.
• Koford Adam. HTTP errors  (англ.). Flickr (23 ноября 2006). — иллюстрации кодов ошибок с 400 по 417 для облегчения запоминания посредством мнемотехники. Архивировано из первоисточника 17 февраля 2012. Проверено 16 января 2010.

Веб и веб-сайты
Глобально	Всемирная паутина (Веб 1.0 • Веб 2.0 • Web 3.0) • Семантическая паутина • Рунет
Локально	Сайт • Портал • Страница • Служба • Кольцо
Виды сайтов и сервисов	Виртуальный атлас • Баннерная сеть • Блог (платформа) • Видеохостинг • Вики (список движков • список сайтов) • Сайт-визитка • Вопрос-ответ • Закладки • Службы знакомств • Каталог ресурсов • Интернет-магазин • Микроблог • Тамблелог • Новостной сайт • Поисковая система (список) • Порносайт • Социальная сеть • BitTorrent-трекер • Файлообменник • Форум (Сервис • Имиджборд) • Фотохостинг • Чат
Создание и обслуживание	Разработка • Мастер • Дизайн • Вёрстка • Программирование • Юзабилити • Модератор • Системный администратор • Поисковая оптимизация (SEO) • Продвижение сайта • Опыт взаимодействия • Регистрация пользователя
Типы макетов, страниц, сайтов	Статический • Динамический • Фиксированный • Резиновый • Динамично эластичный • Адаптивный
Техническое	Веб-сервер (сравнение) • Браузер (список • сравнение) • CMF (список (англ.)) • CMS (список (англ.)) • HTTP (ответы • заголовки) • SPDY • CGI • HTML • XHTML • CSS • JavaScript • DHTML • DOM • XML • AJAX • JSON • Flash • RSS • Atom • Микроформат • favicon.ico • robots.txt • Sitemaps • Карта сайта • .htaccess
Маркетинг	Интернет-маркетинг • Интернет-реклама • Баннер • Контекстная реклама
Социум и культура	Блогосфера • Интернет-сообщество (районное) • Сетевая литература

Материал из Seo Wiki — Поисковая Оптимизация и Программирование

Перейти к: навигация, поиск

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

• 201 Webpage Created
• 403 Access allowed only for registered users
• 507 Insufficient Storage

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше.
Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC.
Введение новых кодов должно производиться только после согласования с IETF.
Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With^{[прим 1]} (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).

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

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

Обзорный список

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

• 1xx: Informational (Информационные).
  • 100 Continue (Продолжать).
  • 101 Switching Protocols (Переключение протоколов).
  • 102 Processing (Идёт обработка).

• 2xx: Success (Успешно).
  • 200 OK (Хорошо).
  • 201 Created (Создано).
  • 202 Accepted (Принято).
  • 203 Non-Authoritative Information (Неавторитетная информация).
  • 204 No Content (Нет содержимого).
  • 205 Reset Content (Сбросить содержимое).
  • 206 Partial Content (Частичное содержимое).
  • 207 Multi-Status (Многостатусный).
  • 226 IM Used (IM использовано).

• 3xx: Redirection (Перенаправление).
  • 300 Multiple Choices (Множество выборов).
  • 301 Moved Permanently (Перемещено окончательно).
  • 302 Found (Найдено).
  • 303 See Other (Смотреть другое).
  • 304 Not Modified (Не изменялось).
  • 305 Use Proxy (Использовать прокси).
  • 306 (зарезервировано).
  • 307 Temporary Redirect (Временное перенаправление).

• 4xx: Client Error (Ошибка клиента).
  • 400 Bad Request (Плохой запрос).
  • 401 Unauthorized (Неавторизован).
  • 402 Payment Required (Необходима оплата).
  • 403 Forbidden (Запрещено).
  • 404 Not Found (Не найдено).
  • 405 Method Not Allowed (Метод не поддерживается).
  • 406 Not Acceptable (Не приемлемо).
  • 407 Proxy Authentication Required (Необходима авторизация прокси).
  • 408 Request Timeout (Время ожидания истекло).
  • 409 Conflict (Конфликт).
  • 410 Gone (Удалён).
  • 411 Length Required (Необходима длина).
  • 412 Precondition Failed (Условие «ложно»).
  • 413 Request Entity Too Large (Запрашиваемые данные слишком большие).
  • 414 Request-URI Too Long (Запрашиваемый URI слишком длинный).
  • 415 Unsupported Media Type (Неподдерживаемый тип данных).
  • 416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим).
  • 417 Expectation Failed (Ожидаемое не приемлемо).
  • 422 Unprocessable Entity (Необрабатываемый экзмепляр).
  • 423 Locked (Заблокировано).
  • 424 Failed Dependency (Невыполненная зависимость).
  • 425 Unordered Collection (Неупорядоченный набор).
  • 426 Upgrade Required (Необходимо обновление).
  • 449 Retry With (Повторить с…).

• 5xx: Server Error (Ошибка сервера).
  • 500 Internal Server Error (Внутренняя ошибка сервера).
  • 501 Not Implemented (Не реализовано).
  • 502 Bad Gateway (Плохой шлюз).
  • 503 Service Unavailable (Сервис недоступен).
  • 504 Gateway Timeout (Шлюз не отвечает).
  • 505 HTTP Version Not Supported (Версия HTTP не поддерживается).
  • 506 Variant Also Negotiates (Вариант тоже согласован).
  • 507 Insufficient Storage (Переполнение хранилища).
  • 509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала).
  • 510 Not Extended (Не расширено).

<span id=»1xx» /> 1xx: Informational (Информационные)

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

<span id=»100″ /> 100 Continue (Продолжать)

Появился в HTTP/1.1.

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

<span id=»101″ /> 101 Switching Protocols (Переключение протоколов)

Появился в HTTP/1.1.

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

<span id=»102″ /> 102 Processing (Идёт обработка)

Появился в WebDAV.

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

<span id=»2xx» /> 2xx: Success (Успешно)

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

<span id=»200″ /> 200 OK (Хорошо)

Появился в HTTP/1.0.

Успешный запрос ресурса.
Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

<span id=»201″ /> 201 Created (Создано)

Появился в HTTP/1.0.

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

<span id=»202″ /> 202 Accepted (Принято)

Появился в HTTP/1.0.

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

<span id=»203″ /> 203 Non-Authoritative Information (Неавторитетная информация)

Появился в HTTP/1.1.

Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

<span id=»204″ /> 204 No Content (Нет содержимого)

Появился в HTTP/1.0.

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

<span id=»205″ /> 205 Reset Content (Сбросить содержимое)

Появился в HTTP/1.1.

Сервер обязывает клиента сбросить введённые пользователем данные.
Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

<span id=»206″ /> 206 Partial Content (Частичное содержимое)

Появился в HTTP/1.1.

Сервер удачно выполнил частичный GET возвратив только часть.
В заголовке Content-Range сервер указывает байтовые диапазоны содержимого.
Особое внимание при работе с подобными ответами следует уделить кэшированию.

См. так же пример докачки и фрагментарного скачивания в статье по HTTP.

<span id=»207″ /> 207 Multi-Status (Многостатусный)

Появился в WebDAV.

Сервер передаёт результаты выполнения сразу нескольких независимых операций.
Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus.
Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

<span id=»226″ /> 226 IM Used (IM использовано)

Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.

<span id=»3xx» /> 3xx: Redirection (Перенаправление)

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

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

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

Поведение клиентов при различных перенаправлениях описано в таблице:

Статус ответа	Кэширование	Если метод не GET или HEAD
301 Moved Permanently	Можно как обычно.	Спросить у пользователя подтверждения и запросить другой ресурс исходным методом.
307 Temporary Redirect	Можно только если указан заголовок Cache-Control или Expires.
302 Found
303 See Other	Никогда нельзя.	Перейти автоматически, но уже методом GET.

См. так же пример перенаправлений в статье по HTTP.

<span id=»300″ /> 300 Multiple Choices (Множество выборов)

Появился в HTTP/1.0.

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

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

<span id=»301″ /> 301 Moved Permanently (Перемещено окончательно)

Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка.
Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

<span id=»302″ /> 302 Found (Найдено)

Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location.
Этот код может быть использован, например, при управляемом сервером согласовании содержимого.
Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

<span id=»303″ /> 303 See Other (Смотреть другое)

Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом.
Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET (см. описание ко всему классу 3xx).

Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска.
После ввода данных браузер делает запрос методом POST включая в тело сообщения введённый текст.
Если обнаружен документ с введённым названием, то сервер отвечает 303 указав в заголовке Location его постоянный адрес.
Тогда браузер гарантировано его запросит методом GET для получения содержимого.
В противном случае сервер просто вернёт клиенту страницу с результатами поиска^{[прим 2]}.

<span id=»304″ /> 304 Not Modified (Не изменялось)

Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента.
При этом сообщение сервера не должно содержать тела.

<span id=»305″ /> 305 Use Proxy (Использовать прокси)

Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка.
Данный код ответа могут использовать только исходные HTTP-сервера (не прокси).

<span id=»306″ /> 306 (зарезервировано)

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше, в настоящий момент зарезервировано.

<span id=»307″ /> 307 Temporary Redirect (Временное перенаправление)

Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен по другому URI (указывается в поле Location заголовка).
Этот код был введён вместе с 303 вместо 302-ого для избежания неоднозначности (см. описание ко всему классу 3xx).

<span id=»4xx» /> 4xx: Client Error (Ошибка клиента)

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

<span id=»400″ /> 400 Bad Request (Плохой запрос)

Появился в HTTP/1.0.

Запрос не понят сервером из-за наличия синтаксической ошибки.
Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

<span id=»401″ /> 401 Unauthorized (Не авторизован)

Появился в HTTP/1.0.

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

<span id=»402″ /> 402 Payment Required (Необходима оплата)

Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем.
В настоящий момент не используется.

Обратите внимание что этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.
Если не оплачена услуга хостинга сайта, то логичней возвращать клиенту ответ из класса 5xx.
Например, как cPanel возвращает ответ 509 (Bandwidth Limit Exceeded) когда площадкой превышен лимит на потребление трафика.

<span id=»403″ /> 403 Forbidden (Запрещено)

Появился в HTTP/1.0.

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

Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 (или 407 для прокси). В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого ПО.

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

Наиболее вероятными причинами ограничения могут послужить:

• Попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов.
• Для доступа требуется аутентификация не средствами HTTP (например, для доступа к CMS или разделу для зарегистрированных пользователей).
• Сервер не удовлетворён IP-адресом клиента (например, временная блокировка из-за частых обращений или же на этапе разработки приложения доступ разрешён только некоторым IP).

<span id=»404″ /> 404 Not Found (Не найдено)

Появился в HTTP/1.0.

Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.
Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410.
Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

<span id=»405″ /> 405 Method Not Allowed (Метод не применим)

Появился в HTTP/1.1.

Указанный клиентом метод нельзя применить к текущему ресурсу.
В ответе сервер должен указать доступные методы в заголовке Allow разделив их запятой.

Обратите внимание что эту ошибку сервер должен возвращать если метод ему известен, но он не применим именно к указанному в запросе ресурсу.
Если же указанный метод не применим на всём сервере, то клиенту нужно вернуть ответ 501 (Not Implemented).

<span id=»406″ /> 406 Not Acceptable (Не приемлемо)

Появился в HTTP/1.1.

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

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

<span id=»407″ /> 407 Proxy Authentication Required (Необходима авторизация прокси)

Появился в HTTP/1.1.

Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера.
Механизм аналогичен идентификации на исходном сервере.

<span id=»408″ /> 408 Request Timeout (Время ожидания истекло)

Появился в HTTP/1.1.

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

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

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

<span id=»409″ /> 409 Conflict (Конфликт)

Появился в HTTP/1.1.

Запрос не может быть выполнен из-за конфликтного обращения к ресурсу.
Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

<span id=»410″ /> 410 Gone (Удалён)

Появился в HTTP/1.1.

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

<span id=»411″ /> 411 Length Required (Необходима длина)

Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса.
Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

Такой ответ вполне естественнен для запросов типа POST и PUT.
Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём.
Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку разрывая соединение когда клиент действительно пришлёт слишком объёмное сообщение.

<span id=»412″ /> 412 Precondition Failed (Условие «ложно»)

Появился в HTTP/1.1.

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

<span id=»413″ /> 413 Request Entity Too Large (Запрашиваемые данные слишком большие)

Появился в HTTP/1.1.

Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации.
Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

<span id=»414″ /> 414 Request-URI Too Long (Запрашиваемый URI слишком длинный)

Появился в HTTP/1.1.

Сервер не может обработать запрос из-за слишком длинного указанного URI.
Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

<span id=»415″ /> 415 Unsupported Media Type (Неподдерживаемый тип данных)

Появился в HTTP/1.1.

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

<span id=»416″ /> 416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим)

Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range.
Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка.
Данный ответ не следует использовать при передаче типа multipart/byteranges.

<span id=»417″ /> 417 Expectation Failed (Ожидаемое не приемлемо)

Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

<span id=»422″ /> 422 Unprocessable Entity (Необрабатываемый экземпляр)

Введено в WebDAV.

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

<span id=»423″ /> 423 Locked (Заблокировано)

Введено в WebDAV.

Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

<span id=»424″ /> 424 Failed Dependency (Невыполненная зависимость)

Введено в WebDAV.

Реализация текущего запроса может зависеть от успешности выполнения другой операции.
Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

<span id=»425″ /> 425 Unordered Collection (Неупорядоченный набор)

Введено в черновике по WebDAV Advanced Collections Protocol.

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

<span id=»426″ /> 426 Upgrade Required (Необходимо обновление)

Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

Сервер указывает клиенту на необходимость обновить протокол.
Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

<span id=»449″ /> 449 Retry With (Повторить с…)

Введено корпорацией Microsoft для WebDAV.

Возвращается сервером если для обработки запроса от клиента поступило не достаточно информации.
При этом в заголовок ответа помещается поле Ms-Echo-Request.

В настоящий момент как минимум используется программой Microsoft Money.
Более подробную информацию по данному коду ответа можно получить в библиотеке MSDN.

<span id=»5xx» /> 5xx: Server Error (Ошибка сервера)

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

<span id=»500″ /> 500 Internal Server Error (Внутренняя ошибка сервера)

Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

<span id=»501″ /> 501 Not Implemented (Не реализовано)

Появился в HTTP/1.0.

Сервер не поддерживает возможностей, необходимых для обработки запроса.

Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.
Если же метод серверу известен, но он не применим только к данному ресурсу, то нужно вернуть ответ 405 (Method Not Allowed).

<span id=»502″ /> 502 Bad Gateway (Плохой шлюз)

Появился в HTTP/1.0.

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

<span id=»503″ /> 503 Service Unavailable (Сервис недоступен)

Появился в HTTP/1.0.

Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее).
В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос.
Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

<span id=»504″ /> 504 Gateway Timeout (Шлюз не отвечает)

Появился в HTTP/1.1.

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

<span id=»505″ /> 505 HTTP Version Not Supported (Версия HTTP не поддерживается)

Появился в HTTP/1.1.

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

<span id=»506″ /> 506 Variant Also Negotiates (Вариант тоже согласован)

Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

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

<span id=»507″ /> 507 Insufficient Storage (Переполнение хранилища)

Введено в WebDAV.

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

<span id=»509″ /> 509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала)

Введено в расширении bw/limited (mod_bwlimited) к Apache для cPanel.

Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика.
В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру.
В настоящий момент данный код не описан ни в одном RFC и используется только модулем bw/limited, входящем в панель управления хостингом cPanel.

<span id=»510″ /> 510 Not Extended (Не расширено)

Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

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

Интересные факты

• В основе шутливого протокола HTCPCP для работы с кофеварками лежит HTTP. Разработчики HTCPCP ввели дополнительный статус-код 418 «I’m a teapot» (русск. «Я — чайник») для случаев если пользователь пытается приготовить кофе с помощью заварного чайника. Как сказано в самой спецификации ответ в этом случае может быть коротким и жёстким^[4].

Примечания

Источники

См. также

• Протокол HTTP
• Протокол WebDAV
• Протокол HTCPCP
• Разделы «Обработка ошибок» и «Перенаправление (редирект)» в статье «.htaccess».

Смежные темы:

• Список заголовков HTTP
• Протокол TLS
• Дельта-кодирование

Ссылки

Основные документы по протоколу HTTP (по убыванию даты публикации):

• Hypertext Transfer Protocol (HTTP) Status Code Registry (англ.). IANA (17 октября 2007). — реестр кодов состояния HTTP. Проверено 30 июля 2009.
• RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (UC Irvine), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), Frystyk Henrik (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT) — обновление протокола HTTP версии 1.1.
• RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (UC Irvine), Gettys Jim (DEC), Mogul J. (DEC), Frystyk Henrik (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
• RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0» (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (UC Irvine), Frystyk Henrik (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.

Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации):

• RFC 4918 Proposed Standard «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)» (англ.) (русск. «Расширения HTTP для распределённой авторской работы и управления версиями через веб (WEBDAV)»); IETF, июнь 2007; Dusseault Ed. L. (CommerceNet) — поздняя спецификация по протоколу WebDAV, заместившая RFC 2518.
• RFC 3229 Proposed standard «Delta encoding in HTTP» (англ.) (русск. «Дельта-кодирование в HTTP»); IETF, январь 2002; Mogul J. (Compaq WRL), Krishnamurthy B. (AT&T), Douglis F. (AT&T), Feldmann A. (Univ. of Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA).
• RFC 2817 Proposed Standard «Upgrading to TLS Within HTTP/1.1» (англ.) (русск. «Обновление к TLS совместно с HTTP/1.1»); IETF, май 2000; Khare Rohit (4K Associates/UC Irvine), Lawrence S. (Agranat Systems, Inc.) — обновление к RFC 2616 для описания работы HTTP и TLS.
• RFC 2774 Experimental «An HTTP Extension Framework» (англ.) (русск. «Каркас расширений HTTP»); IETF, февраль 2000; Nielsen H. (Microsoft), Leach P. (Microsoft), Lawrence S. (Agranat Systems).
• Internet Draft «WebDAV Advanced Collections Protocol» (русск. «Протокол продвинутых коллекций WebDAV»); IETF, 18 июня 1999; Slein J. (Xerox), Whitehead Jr. E. J. (UC Irvine), Davis J. (CourseNet), Clemm G. (Rational), Fay C. (FileNet), Crawford J. (IBM), Chihaya T. (DataChannel) — управление коллекциями в WebDAV; просрочился 18 декабря 1999 года.
• RFC 2518 Proposed Standard «HTTP Extensions for Distributed Authoring — WEBDAV» (англ.) (русск. «Расширения HTTP для распределённой авторской работы — WEBDAV»); IETF, февраль 1999; Goland Y. (Microsoft), Whitehead E. (UC Irvine), Faizi A. (Netscape), Carter S. (Novell), Jensen D. (Novell) — первая спецификация по протоколу WebDAV (замещена RFC 4918).
• RFC 2295 Experimental «Transparent Content Negotiation in HTTP» (англ.) (русск. «Прозрачное согласование содержимого в HTTP»); IETF, март 1998; Holtman K. (TUE), Mutz A. (Hewlett-Packard).

Дополнительные материалы:

• Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions (англ.). Microsoft (14 марта 2007). — описание поддержки клиентских расширений в протоколе WebDAV. Проверено 30 июля 2009.
• RFC 2324 Informational «Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)» (англ.) (русск. «Гипертекстовый протокол управления кофеваркой (HTCPCP/1.0)»); IETF, 1 апреля 1998; Masinter L..
• KB 318380 Коды состояния служб IIS (рус.). Microsoft (4 декабря 2007). — список расширенных кодов состояния для протоколов HTTP и FTP. Проверено 16 января 2010.
• Dean Alan. HTTP/1.1 (DELETE, GET, HEAD, PUT, POST) (англ.) (23 января 2007). — диаграмма принятия веб-сервером решений об ответе в зависимости от заголовков (схема в формате GIF). Проверено 16 января 2010.
• Koford Adam. HTTP errors (англ.). Flickr (23 ноября 2006). — иллюстрации кодов ошибок с 400 по 417 для облегчения запоминания посредством мнемотехники. Проверено 16 января 2010.

de:HTTP-Statuscode

en:List of HTTP status codes
es:Anexo:Códigos de estado HTTP
fr:Liste des codes HTTP
is:Listi yfir HTTP-stöðukóða
it:Elenco dei codici di stato HTTP
ja:HTTPステータスコード
nl:Lijst van HTTP-statuscodes
no:Liste over HTTP-statuskoder
pl:Kod odpowiedzi HTTP
sv:Lista över HTTP-statuskoder
th:รายชื่อรหัสสถานภาพของเอชทีทีพี
tr:HTTP durum kodları
zh:HTTP状态码

→