Ошибки http 400 499

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. The status code is deprecated.^[4]

103 Early Hints (RFC 8297)

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

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.^[6]

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.^[7][8]

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.^[9]

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.^[10]

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.^[11]

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»),^[12] 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.^[11]

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,^[14] 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.^[15] Sipgate uses this code if an account does not have sufficient funds to start a call.^[16] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[17] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[18]

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.^[19]

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.^[20]

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.^[21]

417 Expectation Failed

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

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.^[23] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[24][25][26] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[27][28]

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.^[9]

423 Locked (WebDAV; RFC 4918)

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

424 Failed Dependency (WebDAV; RFC 4918)

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

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.^[29]

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.^[29]

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.^[29]

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.^[30] 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.^[31]

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.^[32]

507 Insufficient Storage (WebDAV; RFC 4918)

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

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 fulfil it.^[33]

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).^[29]

Unofficial codes

The following codes are not specified by any standard.

218 This is fine (Apache HTTP Server)

Used by Apache servers. A catch-all error condition allowing the passage of message bodies through the server when the ProxyErrorOverride setting is enabled. It is displayed in this situation instead of a 4xx or 5xx error message.^[34]

419 Page Expired (Laravel Framework)

Used by the Laravel Framework when a CSRF Token is missing or expired.^{[citation needed]}

420 Method Failure (Spring Framework)

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

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.^[36] 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.^[37]

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.^[38]

498 Invalid Token (Esri)

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

499 Token Required (Esri)

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

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.^[40]

529 Site is overloaded

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

530 Site is frozen

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

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.^[43]

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.^[44]

449 Retry With

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

451 Redirect

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

IIS sometimes uses additional decimal sub-codes for more specific information,^[48] 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.^[49][50]

444 No Response

Used internally^[51] 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.^[52]

520 Web Server Returned an Unknown Error

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

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.^[54]

530

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

AWS Elastic Load Balancing

Amazon Web Services’ Elastic Load Balancing adds a few custom return codes to signal issues either with the client request or with the origin server.^[56]

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.^[56]

463

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

464

Incompatible protocol versions between Client and Origin server.^[56]

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.^[56]

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.^[57][58]

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.^[59]

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 at the Internet Assigned Numbers Authority
• HTTP status codes at http-statuscode.com
• MDN status code reference at mozilla.org

400 Bad Request

Запрос не был распознан сервером из-за возможной ошибки синтаксиса. Клиент не должен повторно отправлять этот запрос без модификации.

Запрос требует авторизации пользователя¹⁾. С этим статусом сервер должен отправить в заголовке поле WWW-Authenticate с запросом авторизации. Клиент может повторно отправить свой запрос с включением в заголовок реквизитов авторизации (поле Authorization). Если запрос клиента уже содержал заголовок с реквизитами, ответ 401 означает, что реквизиты неверны и авторизация не состоялась. При получении статуса 401 пользователю должна быть представлена форма для ввода реквизитов доступа.

402 Payment Required

Данный ответ подразумевает оплату доступа к ресурсу. Не используется, зарезервирован для применения в будущем²⁾.

403 Forbidden

Доступ запрещен. Сервер распознал запрос, но в доступе отказано. Отказ не связан с авторизацией, а обусловлен настройками сервера, клиент не должен повторять запрос к запрещенной области. Сервер должен отправить сообщение с объяснением отказа. Если доступ невозможен временно и сообщение о запрете нежелательно, то вместо этого статуса нужно использовать 404.

404 Not Found

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

405 Method Not Allowed

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

406 Not Acceptable

407 Proxy Authentication Required

Этот ответ аналогичен 401, но требует от клиента авторизации на прокси-сервере. Прокси должен прислать в ответе поле заголовка Proxy-Authenticate, клиент может повторить запрос с соответствующим полем заголовка Proxy-Authorization. В остальном действует та же процедура HTTP-авторизации.

408 Request Timeout

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

409 Conflict

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

410 Gone

411 Length Required

Сервер отказал в доступе по запросу с не определенным полем Content-Length в заголовке. Клиент может повторить запрос, если добавит в заголовок поле Content-Length с указанием длины «тела» запроса. Обычно применимо для POST-запросов.

412 Precondition Failed

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

413 Request Entity Too Large

Сервер отказывает в обработке запроса, поскольку запрошенный объект слишком велик — больше, чем сервер в состоянии обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать запрос. Если это состояние является временным, сервер должен включить в заголовок ответа поле Retry-After с указанием, через какое время клиент может попытаться повторить запрос.

414 Request-URI Too Long

415 Unsupported Media Type

Формат объекта запроса не поддерживается запрашиваемым ресурсом для данного метода запроса.

416 Requested Range Not Satisfiable

417 Expectation Failed

Наверх

2 января, 2015 12:50 пп
15 441 views
| Комментариев нет

Cloud Server

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

• 1хх – информационные коды;
• 2хх – успех;
• 3хх – перенаправление;
• 4хх – ошибка клиента;
• 5хх – ошибка сервера.

Это руководство фокусируется на выявлении и устранении наиболее часто встречающихся кодов ошибок HTTP (то есть кодов состояния 4xx и 5xx) с точки зрения системного администратора. В некоторых ситуациях веб-сервер отвечает на запрос определенным кодом ошибки; рассмотрим общие возможные причины и решения.

Краткий обзор ошибок клиента и сервера

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

Ошибки сервера (коды состояния HTTP 500-599) возникают тогда, когда веб-сервер не в состоянии обработать запрос из-за какой-либо ошибки или сбоя.

Общие советы по устранению ошибок HTTP

• При использовании веб-браузера для тестирования веб-сервера не забудьте обновить браузер после внесения изменений в настройки сервера.
• Проверяйте логи сервера, чтобы получить подробные сведения о том, как сервер обрабатывает запросы. Например, веб-серверы Apache и Nginx создают два файла по имени access.log и error.log, в которых можно найти соответствующую информацию.
• Запомните: определения кодов состояния HTTP являются частью стандарта, который реализуется обслуживающим запросы приложением. Это означает, что фактический код состояния, который возвращается в результате, зависит от того, как программное обеспечение сервера обрабатывает конкретную ошибку.

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

Ошибка 400 Bad Request

Код статуса 400, или ошибка Bad Request («неверный запрос») означает, что синтаксис запроса HTTP, отправленного на сервер, неверен.

Как правило, причины возникновения ошибки 400 Bad Request таковы:

• Куки пользователя, связанные с сайтом, повреждены. Чтобы решить эту проблему,, попробуйте очистить кэш браузера и файлы cookie.
• Искаженный запрос из-за неисправного браузера.
• Искаженный запрос из-за ошибки пользователя при формировании HTTP-запроса вручную (например, неправильное использование curl).

Ошибка 401 Unauthorized

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

Например, ошибка 401 Unauthorized может возникнуть, если пользователь пытается получить доступ к ресурсу, который защищен HTTP-авторизацией (как в этом руководстве по Nginx). В подобной ситуации ошибка 401 будет появляться снова и снова до тех пор, пока пользователь не предоставит корректный логин и пароль (который внесен в файл .htpasswd).

Ошибка 403 Forbidden

Код состояния 403, или ошибка Forbidden («запрещено») значит, что запрос пользователя был отправлен верно, но сервер отказывается обслуживать его в связи с отсутствием разрешения на доступ к запрашиваемому ресурсу. В этом разделе описаны наиболее распространенные причины возникновения ошибки 403.

Права на файл

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

Чтобы привести пример устранения ошибки 403, предположим, что:

• пользователь пытается получить доступ к индексному файлу (http://example.com/index.html);
• рабочий процесс веб-сервера принадлежит пользователю www-data;
• индексный файл на сервере находится в /usr/share/nginx/html/index.html.

Итак, если пользователь получает ошибку 403 Forbidden, убедитесь, что пользователь www-data имеет права на чтение файла. Как правило, в подобной ситуации нужно просто изменить права на файл. Это можно сделать несколькими способами, но в данном случае подойдет вот эта команда:

sudo chmod o=r /usr/share/nginx/html/index.html

Файл .htaccess

Еще одна потенциальная причина возникновения ошибки 403 (часто это делается намеренно) – использование файла .htaccess. При помощи файла .htaccess можно запретить конкретным IP-адресам (или диапазонам адресов) доступ к определенным ресурсам.

Если пользователи неожиданно получают ошибку 403 Forbidden, убедитесь, что она не была вызвана настройками файла .htaccess.

Несуществующий индексный файл

Если пользователь пытается получить доступ к каталогу, который не имеет стандартного индексного файла, а листинг каталога (directory listing) отключен, веб-сервер будет возвращать ошибку 403 Forbidden. Такое случится, если, например, пользователь попытается получить доступ к каталогу http://example.com/emptydir/, а в каталоге emptydir на сервере нет индексного файла. Листинг каталога можно включить в конфигурациях сервера.

Ошибка 404 Not Found

Код статуса 404, или ошибка Not Found («не найдено») значит, что пользователь может взаимодействовать с сервером, но требуемый файл или ресурс отсутствует.

Ошибки 404 могут возникнуть в самых различных ситуациях. Ниже приведен список советов, которые помогут устранить проблему в случае, если пользователь неожиданно получил 404 Not Found:

• Проверьте ссылку, которая направляет пользователя на сервер, на наличие ошибок или опечаток.
• Возможно, пользователь ввел неверный URL.
• Может быть, нужного файла не существует в указанном месте на сервере; убедитесь, что запрашиваемый ресурс не был перемещен или удален с сервера.
• Проверьте, правильно ли указано местонахождение корневого каталога (document root) в конфигурации сервера.
• Возможно, пользователь, которому принадлежит рабочий процесс веб-сервера, не имеет соответствующих прав, чтобы открыть каталог, в котором находится запрашиваемый файл. Для доступа к каталогу нужны права на чтение и выполнение.
• Если пользователь переходит к ресурсу по символической ссылке, убедитесь, что веб-сервер настроен для поддержки символических ссылок.

Ошибка 500 Internal Server Error

Код состояния 500, или ошибка Internal Server Error («внутренняя ошибка сервера») означает, что сервер не может обработать запрос по неизвестной причине. Иногда этот код появляется в ситуациях, когда более подходящими являются  другие сообщения об ошибках 5xx.

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

Ошибка 502 Bad Gateway

Код состояния 502, или ошибка Bad Gateway («ошибочный шлюз») значит, что запрашиваемый сервер является шлюзом или прокси-сервером, и он не получает валидных ответов от серверов бэкэнда, которые на самом деле выполнили запрос.

Если речь идет об обратном прокси-сервере (например, о балансировщике нагрузки), убедитесь, что:

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

Ошибка 503 Service Unavailable

Код состояния 503, или ошибка Service Unavailable («сервис недоступен») означает, что сервер перегружен или находится на обслуживании; такой сервис должен стать доступным в течение некоторого времени.

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

Ошибка 504 Gateway Timeout

Код состояния 504, или ошибка Gateway Timeout («шлюз не отвечает») значит, что данный сервер является шлюзом или прокси-сервером, и он не получает ответа от бэкэнда в пределах допустимого периода времени.

Как правило, это происходит по следующим причинам:

• Плохое сетевое соединение между серверами;
• Внутренний сервер, который выполняет запрос, работает слишком медленно;
• В настройках сервера задано слишком короткое время ожидания шлюза или прокси-сервера.

Заключение

Теперь вы знакомы с основными кодами ошибок HTTP и знаете некоторые пути решения этих проблем.

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

Tags: Cloud Server, HTTP, HTTP status code, VPS

HTTP status codes are like short notes from a server that get tacked onto a web page. They’re not actually part of the site’s content. Instead, they’re messages from the server letting you know how things went when it received the request to view a certain page.

These kinds of messages are returned every time your browser interacts with a server, even if you don’t see them. If you’re a website owner or developer, understanding HTTP status codes is critical. When they do show up, HTTP status codes are an invaluable tool for diagnosing and fixing website configuration errors.

This article introduces several server status and error codes, and explains what they reveal about what’s happening on the server behind the scenes.

Let’s dive in!

Prefer to watch the video version?

What Are HTTP Status Codes?

Every time you click on a link or type in a URL and press Enter, your browser sends a request to the webserver for the site you’re trying to access. The server receives and processes the request, and then sends back the relevant resources along with an HTTP header.

HTTP status codes are delivered to your browser in the HTTP header. While status codes are returned every single time your browser requests a web page or resource, most of the time you don’t see them.

It’s usually only when something goes wrong that you might see one displayed in your browser. This is the server’s way of saying: “Something isn’t right. Here’s a code that explains what went wrong.”

If you want to see the status codes that your browser doesn’t normally show you, there are many different tools that make it easy. Browser extensions are available for developer-friendly platforms such as Chrome and Firefox, and there are many web-based header fetching tools like Web Sniffer.

To see HTTP status codes with one of these tools, look for the line appearing near the top of the report that says “Status: HTTP/1.1”. This will be followed by the status code that was returned by the server.

Understanding HTTP Status Code Classes

HTTP status codes are divided into 5 “classes”. These are groupings of responses that have similar or related meanings. Knowing what they are can help you quickly determine the general substance of a status code before you go about looking up its specific meaning.

The five classes include:

• 100s: Informational codes indicating that the request initiated by the browser is continuing.
• 200s: Success codes returned when browser request was received, understood, and processed by the server.
• 300s: Redirection codes returned when a new resource has been substituted for the requested resource.
• 400s: Client error codes indicating that there was a problem with the request.
• 500s: Server error codes indicating that the request was accepted, but that an error on the server prevented the fulfillment of the request.

Within each of these classes, a variety of server codes exist and may be returned by the server. Each individual code has a specific and unique meaning, which we’ll cover in the more comprehensive list below.

Why HTTP Status Codes and Errors Matter for Search Engine Optimization (SEO)

Search engine bots see HTTP status codes while they’re crawling your site. In some cases, these messages can influence if and how your pages get indexed, as well as how search engines perceive the health of your site.

Generally speaking, 100- and 200-level HTTP status codes won’t have much impact on your SEO. They signal that everything is working as it should on your site, and enable search engine bots to continue on their way. However, they aren’t going to boost your rankings either.

For the most part, it’s the higher-level codes that matter for SEO. 400- and 500-level responses can prevent bots from crawling and indexing your pages. Too many of these errors can also indicate that your site isn’t of high quality, possibly lowering your rankings.

300-level codes have a bit more complicated relationship with SEO. The main thing you need to know to understand their impact is the difference between permanent and temporary redirects, which we’ll cover in more detail in the relevant section below.

In a nutshell, however, permanent redirects share link equity from backlinks, but temporary ones do not. In other words, when you use temporary redirects for pages that have moved, you lose the SEO advantage of all the link building you’ve done.

Checking for HTTP Status Codes in Google Search Console

One way to monitor how Google perceives the HTTP status codes on your site is to use Google Search Console. You can view 300-, 400-, and 500-level status codes in the Coverage report:

This area of your dashboard shows four types of content on your site:

• Pages that return errors.
• Valid pages that have warnings.
• Resources that are valid.
• Content excluded from the index.

You may find pages with 300-, 400-, and 500-level HTTP status codes under the Excluded, Error, or Valid with warnings sections, depending on the type of code. For instance, 301 redirects may be listed under Excluded as Page with redirect:

400- and 500-level status codes will likely turn up under Error.

Another way to view HTTP status codes is by using the URL Inspection tool. If Google is unable to index a specific page due to an error, you’ll see that here:

For more tips on using Google Search Console, check out our comprehensive guide to the platform.

A Complete Guide and List of HTTP Status Codes

While there are over 40 different server status codes, you’ll likely encounter fewer than a dozen on a regular basis. Below, we’ve covered the more common ones, as well as a few of the more obscure codes you may still run across.

100 Status Codes

A 100-level status code tells you that the request you’ve made to the server is still in progress for some reason. This isn’t necessarily a problem, it’s just extra information to let you know what’s going on.

• 100: “Continue.” This means that the server in question has received your browser’s request headers, and is now ready for the request body to be sent as well. This makes the request process more efficient since it prevents the browser from sending a body request even though the headers have been rejected.
• 101: “Switching protocols.” Your browser has asked the server to change protocols, and the server has complied.
• 103: “Early hints.” This returns some response headers before the rest of the server’s response is ready.

200 Status Codes

This is the best kind of HTTP status code to receive. A 200-level response means that everything is working exactly as it should.

• 200: “Everything is OK.” This is the code that is delivered when a web page or resource acts exactly the way it’s expected to.
• 201: “Created.” The server has fulfilled the browser’s request, and as a result, has created a new resource.
• 202: “Accepted.” The server has accepted your browser’s request but is still processing it. The request ultimately may or may not result in a completed response.
• 203: “Non-Authoritative Information.” This status code may appear when a proxy is in use. It means that the proxy server received a 200 “Everything is OK” status code from the origin server, but has modified the response before passing it on to your browser.
• 204: “No Content.” This code means that the server has successfully processed the request, but is not going to return any content.
• 205: “Reset Content.” Like a 204 code, this means that how server has processed the request but is not going to return any content. However, it also requires that your browser resets the document view.
• 206: “Partial Content.” You may see this status code if your HTTP client (also known as your browser) uses ‘range headers’. This enables your browser to resume paused downloads, as well as to split a download into multiple streams. A 206 code is sent when a range header causes the server to send only part of the requested resource.

300 Status Codes

Redirection is the process used to communicate that a resource has been moved to a new location. There are several HTTP status codes that accompany redirections, in order to provide visitors with information about where to find the content they’re looking for.

• 300: “Multiple Choices.” Sometimes, there may be multiple possible resources the server can respond with to fulfill your browser’s request. A 300 status code means that your browser now needs to choose between them. This may occur when there are multiple file type extensions available, or if the server is experiencing word sense disambiguation.
• 301: “The requested resource has been moved permanently.” This code is delivered when a web page or resource has been permanently replaced with a different resource. It is used for permanent URL redirection.
• 302: “The requested resource has moved, but was found.” This code is used to indicate that the requested resource was found, just not at the location where it was expected. It is used for temporary URL redirection.
• 303: “See Other.” Understanding a 303 status code requires that you know the difference between the four primary HTTP request methods. Essentially, a 303 code tells your browser that it found the resource your browser requested via POST, PUT, or DELETE. However, to retrieve it using GET, you need to make the appropriate request to a different URL than the one you previously used.
• 304: “The requested resource has not been modified since the last time you accessed it.” This code tells the browser that the resources stored in the browser cache haven’t changed. It’s used to speed up web page delivery by reusing previously-downloaded resources.
• 307: “Temporary Redirect.” This status code has replaced 302 “Found” as the appropriate action when a resource has been temporarily moved to a different URL. Unlike the 302 status code, it does not allow the HTTP method to change.
• 308: “Permanent Redirect.” The 308 status code is the successor to the 301 “Moved Permanently” code. It does not allow the HTTP method to change and indicates that the requested resource is now permanently located at a new URL.

400 Status Codes

At the 400 level, HTTP status codes start to become problematic. These are error codes specifying that there’s a fault with your browser and/or request.

• 400: “Bad Request.” The server can’t return a response due to an error on the client’s end. See our guide for resolving this error.
• 401: “Unauthorized” or “Authorization Required.” This is returned by the server when the target resource lacks valid authentication credentials. You might see this if you’ve set up basic HTTP authentication using htpasswd.

• 402: “Payment Required.” Originally, this code was created for use as part of a digital cash system. However, that plan never followed through. Instead, it’s used by a variety of platforms to indicate that a request cannot be fulfilled, usually due to a lack of required funds. Common instances include:
  • You’ve reached your daily request limit to the Google Developers API.
  • You haven’t paid your Shopify fees and your store has been temporarily deactivated.
  • Your payment via Stripe has failed, or Stripe is trying to prevent a fraudulent payment.
• 403: “Access to that resource is forbidden.” This code is returned when a user attempts to access something that they don’t have permission to view. For example, trying to reach password-protected content without logging in might produce a 403 error.
• 404: “The requested resource was not found.” This is the most common error message of them all. This code means that the requested resource does not exist, and the server does not know if it ever existed.
• 405: “Method not allowed.” This is generated when the hosting server (origin server) supports the method received, but the target resource doesn’t.
• 406: “Not acceptable response.” The requested resource is capable of generating only content that is not acceptable according to the accept headers sent in the request.
• 407: “Proxy Authentication Required.” A proxy server is in use and requires your browser to authenticate itself before continuing.
• 408: “The server timed out waiting for the rest of the request from the browser.” This code is generated when a server times out while waiting for the complete request from the browser. In other words, the server didn’t get the full request that was sent by the browser. One possible cause could be net congestion resulting in the loss of data packets between the browser and the server.
• 409: “Conflict.” A 409 status code means that the server couldn’t process your browser’s request because there’s a conflict with the relevant resource. This sometimes occurs due to multiple simultaneous edits.
• 410: “The requested resource is gone and won’t be coming back.” This is similar to a 404 “Not Found” code, except a 410 indicates that the condition is expected and permanent.
• 411: “Length Required.” This means that the requested resource requires that the client specify a certain length and that it did not.
• 412: “Precondition Failed.” Your browser included certain conditions in its request headers, and the server did not meet those specifications.
• 413: “Payload Too Large” or “Request Entity Too Large.” Your request is larger than the server is willing or able to process.
• 414: “URI Too Long.” This is usually the result of a GET request that has been encoded as a query string that is too large for the server to process.
• 415: “Unsupported Media Type.” The request includes a media type that the server or resource doesn’t support.
• 416: “Range Not Satisfiable.” Your request was for a portion of a resource that the server is unable to return.
• 417: “Expectation Failed.” The server is unable to meet the requirements specified in the request’s expect header field.
• 418: “I’m a teapot.” This code is returned by teapots that receive requests to brew coffee. It’s also an April Fool’s Joke from 1998.

• 422: “Unprocessable Entity.” The client request contains semantic errors, and the server can’t process it.
• 425: “Too Early.” This code is sent when the server is unwilling to process a request because it may be replayed.
• 426: “Upgrade Required.” Due to the contents of the request’s upgrade header field, the client should switch to a different protocol.
• 428: “Precondition Required.” The server requires conditions to be specified before processing the request.
• 429: “Too many requests.” This is generated by the server when the user has sent too many requests in a given amount of time (rate-limiting). This can sometimes occur due to bots or scripts attempting to access your site. In this case, you might want to try changing your WordPress login URL. You can also check out our guide to fixing a 429 “Too Many Requests” error.

• 431: “Request Header Fields Too Large.” The server can’t process the request because the header fields are too large. This may indicate a problem with a single header field, or all of them collectively.
• 451: “Unavailable for Legal Reasons.” The operator of the server has received a demand to prohibit access to the resource you’ve requested (or a set of resources including the one you’ve requested). Fun fact: This code is a reference to Ray Bradbury’s novel Fahrenheit 451.
• 499: “Client closed request.” This is returned by NGINX when the client closes the request while Nginx is still processing it.

500 Status Codes

500-level status codes are also considered errors. However, they denote that the problem is on the server’s end. This can make them more difficult to resolve.

• 500: “There was an error on the server and the request could not be completed.” This is generic code that simply means “internal server error”. Something went wrong on the server and the requested resource was not delivered. This code is typically generated by third-party plugins, faulty PHP, or even the connection to the database breaking. Check out our tutorials on how to fix the error establishing a database connection and other ways to resolve a 500 internal server error.

• 501: “Not Implemented.” This error indicates that the server does not support the functionality required to fulfill the request. This is almost always a problem on the web server itself, and usually must be resolved by the host. Check out our recommendations on how to resolve a 501 not implemented error.
• 502: “Bad Gateway.” This error code typically means that one server has received an invalid response from another, such as when a proxy server is in use. Other times a query or request will take too long, and so it is canceled or killed by the server and the connection to the database breaks. For more details, see our in-depth tutorial on how to fix the 502 Bad Gateway error.
• 503: “The server is unavailable to handle this request right now.” The request cannot be completed at this point in time. This code may be returned by an overloaded server that is unable to handle additional requests. We have a full guide on how to fix the 503 Service Unavailable Error.
• 504: “The server, acting as a gateway, timed out waiting for another server to respond.” This is the code returned when there are two servers involved in processing a request, and the first server times out waiting for the second server to respond. You can read more about how to fix 504 errors in our dedicated guide.
• 505: “HTTP Version Not Supported.” The server doesn’t support the HTTP version the client used to make the request.
• 508: “Resource Limit Is Reached” limits on resources set by your web host have been reached. Check out our tutorial on how to resolve “508 Resource Limit Is Reached” error.
• 509: “Bandwidth Limit Exceeded” means your website is using more bandwidth than your hosting provider allows.
• 511: “Network Authentication Required.” This status code is sent when the network you’re trying to use requires some form of authentication before sending your request to the server. For instance, you may need to agree to the Terms and Conditions of a public Wi-Fi hotspot.
• 521: “Web server is down.” Error 521 is a Cloudflare-specific error message. It means that your web browser was able to successfully connect to Cloudflare, but Cloudflare was not able to connect to the origin web server.
• 525: “SSL Handshake Failed“. Error 525 means that the SSL handshake between a domain using Cloudflare and the origin web server failed. If you are experiencing issues there are five methods you can try to easily fix error 525.

Where to Learn More About HTTP Status Codes

In addition to the HTTP status codes we’ve covered in this list, there are some more obscure ones you may want to learn about. There are several resources you can consult to read up on these rarer codes, including:

• This comprehensive list of HTTP status codes from Wikipedia.
• Status code definitions from the Internet Engineering Task Force (IETF).
• RFC 7231.

Knowing these status codes may help you resolve some unique issues while maintaining your own website, or even when you encounter them on other sites.

They might seem intimidating at first, but HTTP status codes are important to understand what’s happening on your site. Here’s a thorough list of those you should get familiar with! 📟🌐Click to Tweet

Summary

While they may seem confusing or intimidating on the surface, HTTP status codes are actually very informative. By learning some of the common ones, you can troubleshoot problems on your site more quickly.

In this post, we’ve defined 40+ HTTP status codes that you may encounter. From the milder 100- and 200-level codes to the trickier 400- and 500-level errors, making sense of these messages is crucial for maintaining your website and making sure it’s accessible to users.

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.