110 ошибка http

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

HTTP Warning status code 110 Response is Stale is an unofficial HTTP status code, but instead is used in combination with the Warning HTTP Header and included with HTTP response messages to indicate that the HTTP response is stale. Specifically, this HTTP status code is generated by the cache when the time set for the HTTP response has expired.

Example

Warning: 110 www.example.re "Response is Stale"

See also

• HTTP Warning Header

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

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

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

What is the HTTP Protocol? 

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

Application Layer Protocols 

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

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

Transport Layer Protocols 

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

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

Internet Layer Protocols 

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

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

Link Layer Protocols 

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

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

What are Status Codes and Why are They Important? 

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

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

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

HTTP Status Codes Explained 

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

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

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

A Complete List and Overview of HTTP Status Codes

1xx Status Codes:  Informational 

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

100: Continue

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

101: Switching Protocols

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

102: Processing

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

103: Early Hints

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

104-199: Unassigned

Status codes 104 through 199 are currently unassigned.

2xx Status Code: Success 

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

200: OK

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

201: Created

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

202: Accepted

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

203: Non-Authoritative Information

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

204: No Content

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

205: Reset Content 

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

206: Partial Content

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

207: Multi-Status

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

208: Already Reported 

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

209-225: Unassigned 

Status codes 209 through 225 are currently unassigned. 

226: IM Used

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

227-299: Unassigned

Status codes 227 through 299 are currently unassigned. 

3xx: Redirection 

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

300: Multiple Choices

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

301: Moved Permanently

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

302: Found

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

303: See Other

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

304: Not Modified

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

305: Use Proxy

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

306: Unused

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

307: Temporary Redirect 

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

308: Permanent Redirect 

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

309-399: Unassigned

Status codes 309 through 399 are currently unassigned. 

4xx: Client Error 

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

400: Bad Request

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

401: Unauthorized

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

402: Payment Required 

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

403: Forbidden

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

404: Not Found

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

405: Method Not Allowed

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

406: Not Acceptable

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

407: Proxy Authentication Required

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

408: Request Timeout

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

409: Conflict

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

410: Gone

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

411: Length Required

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

412: Precondition Failed

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

413: Request Entity Too Large

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

414: URI Too Long

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

415: Unsupported Media Type

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

416: Range Not Satisfiable

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

417: Expectation Failed 

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

418-420: Unassigned

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

421: Misdirected Request 

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

422: Unprocessable Entity

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

423: Locked

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

424: Failed Dependency 

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

425: Too Early

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

426: Upgrade Required 

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

427: Unassigned

Error status code 427 is currently unassigned. 

428: Precondition Required 

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

429: Too Many Requests 

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

430: Unassigned

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

431 Request Headers Too Large 

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

432-450: Unassigned

Error status codes 432 through 450 are currently unassigned. 

451: Unavailable Due to Legal Reasons 

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

452-499: Unassigned

Error codes 452-499 are currently unassigned.

5xx: Server Error 

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

500: Internal Server Error

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

501: Not Implemented

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

502: Bad Gateway

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

503: Service Unavailable

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

504: Gateway Timeout

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

505: HTTP Version Not Supported

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

506: Variant Also Negotiates

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

507: Insufficient Storage

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

508: Loop Detected

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

509: Unassigned

The 509 server error status code is currently unassigned. 

510: Not Extended

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

511: Network Authorization Required

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

512-599: Unassigned

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

Monitoring HTTP Status Code Responses 

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

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

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

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

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

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

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

[править] Обзорный список

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

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

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

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

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

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

[править] 1xx: Informational (Информационные)

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

[править] 100 Continue (Продолжать)

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

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

[править] 101 Switching Protocols (Переключение протоколов)

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

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

[править] 102 Processing (Идёт обработка)

Появился в WebDAV.

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

[править] 2xx: Success (Успешно)

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

[править] 200 OK (Хорошо)

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

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

[править] 201 Created (Создано) (Транзакция прошла успешно)

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

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

[править] 202 Accepted (Принято)

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

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

[править]

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

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

[править] 204 No Content (Нет содержимого)

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

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

[править] 205 Reset Content (Сбросить содержимое)

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

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

[править] 206 Partial Content (Частичное содержимое)

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

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

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

[править] 207 Multi-Status (Многостатусный)

Появился в WebDAV.

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

[править] 226 IM Used (IM использовано)

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

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

[править] 3xx: Redirection (Перенаправление)

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

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

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

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

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

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

[править] 300 Multiple Choices (Множество выборов)

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

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

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

[править] 301 Moved Permanently (Перемещено окончательно)

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

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

[править] 302 Found (Найдено)

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

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

[править] 303 See Other (Смотреть другое)

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

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

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

[править] 304 Not Modified (Не изменялось)

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

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

[править] 305 Use Proxy (Использовать прокси)

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

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

[править] 306 (зарезервировано)

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

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

[править] 307 Temporary Redirect (Временное перенаправление)

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

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

[править] 4xx: Client Error (Ошибка клиента)

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

[править] 400 Bad Request (Плохой запрос)

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

Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.

[править] 401 Unauthorized (Не авторизован)

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

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

[править] 402 Payment Required (Необходима оплата)

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

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

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

[править] 403 Forbidden (Запрещено)

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

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

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

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

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

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

[править] 404 Not Found (Не найдено)

Это самая распространенная ошибка при пользовании Интернетом (основная причина — ошибка в написании адреса Web-страницы).

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

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

[править] 405 Method Not Allowed (Метод не применим)

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

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

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

[править] 406 Not Acceptable (Не приемлемо)

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

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

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

[править] 407 Proxy Authentication Required (Необходима авторизация прокси)

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

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

[править] 408 Request Timeout (Время ожидания истекло)

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

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

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

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

[править] 409 Conflict (Конфликт)

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

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

[править] 410 Gone (Удалён)

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

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

[править] 411 Length Required (Необходима длина)

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

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

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

[править] 412 Precondition Failed (Условие «ложно»)

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

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

[править] 413 Request Entity Too Large (Размер запроса слишком велик)

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

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

[править] 414 Request-URL Too Long (Запрашиваемый URL слишком длинный)

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

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

[править] 415 Unsupported Media Type (Неподдерживаемый тип данных)

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

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

[править] 416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим)

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

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

[править] 417 Expectation Failed (Ожидаемое не приемлемо)

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

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

[править] 418 I’m a teapot (Я — чайник)

Введено в традиционной первоапрельской RFC 2324: HTCPCP/1.0 (Протокол гипертекстового контроля кофеварками)

Возвращается при попытке заварить кофе в заварном чайнике. Серверу следует вернуть короткий и жёсткий ответ^[4].

[править] 422 Unprocessable Entity (Необрабатываемый экземпляр)

Введено в WebDAV.

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

[править] 423 Locked (Заблокировано)

Введено в WebDAV.

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

[править] 424 Failed Dependency (Невыполненная зависимость)

Введено в WebDAV.

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

[править] 425 Unordered Collection (Неупорядоченный набор)

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

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

[править] 426 Upgrade Required (Необходимо обновление)

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

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

[править] 449 Retry With (Повторить с…)

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

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

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

[править] 456 Unrecoverable Error (Некорректируемая ошибка)

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

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

[править] 5xx: Server Error (Ошибка сервера)

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

[править] 500 Internal Server Error (Внутренняя ошибка сервера)

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

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

[править] 501 Not Implemented (Не реализовано)

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

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

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

[править] 502 Bad Gateway (Плохой шлюз)

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

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

[править] 503 Service Unavailable (Сервис недоступен)

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

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

[править] 504 Gateway Timeout (Шлюз не отвечает)

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

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

[править] 505 HTTP Version Not Supported (Версия HTTP не поддерживается)

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

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

[править] 506 Variant Also Negotiates (Вариант тоже согласован)

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

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

[править] 507 Insufficient Storage (Переполнение хранилища)

Введено в WebDAV.

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

[править] 509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала)

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

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

[править] 510 Not Extended (Не расширено)

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

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

[править] Интересные факты

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

[править] Примечания

[править] Источники

[править] См. также

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

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

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

[править] Ссылки

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

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

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

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

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

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

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