203 ошибка 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.

419 Page Expired (Laravel Framework)

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

420 Method Failure (Spring Framework)

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

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

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

498 Invalid Token (Esri)

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

499 Token Required (Esri)

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

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

529 Site is overloaded

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

530 Site is frozen

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

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

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

449 Retry With

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

451 Redirect

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

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

444 No Response

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

520 Web Server Returned an Unknown Error

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

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

530

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

AWS Elastic Load Balancer

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

460

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

463

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

464

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

561 Unauthorized

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

Caching warning codes (obsoleted)

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

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

110 Response is Stale

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

111 Revalidation Failed

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

112 Disconnected Operation

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

113 Heuristic Expiration

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

199 Miscellaneous Warning

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

214 Transformation Applied

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

299 Miscellaneous Persistent Warning

Same as 199, but indicating a persistent warning.

See also

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

Explanatory notes

References

External links

• «RFC 9110: HTTP Semantics and Content, Section 15 «Status Codes»«.
• Hypertext Transfer Protocol (HTTP) Status Code Registry at the Internet Assigned Numbers Authority
• MDN status code reference at mozilla.org

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. 

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

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

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

Успешный код состояния	Описание успешного кода состояния HTTP севера
200 OK	Успешный код состояния HTTP сервера 200: хорошо Код состояния 200 говорит клиенту о том, что его запрос удачно выполнен.
201 Created	Успешный код состояния HTTP сервера 201: создан Код состояния 201 сообщает нам о том, что новый ресурс был создан успешно.
202 Accepted	Успешный код состояния HTTP сервера 202: принято Код состояния 202 сообщает клиенту о том, что HTTP запрос успешно принят на обработку, но обработка еще не завершена, в этом случае сервер может отказать в обслуживание запроса клиента.
203 Non-authoritative Information	Успешный код состояния HTTP сервера 203: не авторская информация Код состояния 203, отправленный в HTTP ответе, сообщает клиенту о том, что возвращенная в заголовке HTTP  объекта информация – это не оригинал, который есть на первоначальном сервере, а документ, собранный из локальных копий или копий третьей стороны.
204 No Content	Успешный код состояния HTTP сервера 204: нет содержимого Код состояния 204 говорит клиенту о том, что в ответном HTTP сообщении нет тела (про тело объекта HTTP).
205 Reset Content	Успешный код состояния HTTP сервера 205: сбросить содержимое Если браузер получит код состояния 205, то он должен очистить форму, чтобы дать пользователю ввести дополнительные данные.
206 Partial Content	Успешный код состояния HTTP сервера 206: частичное содержимое Код состояния 206 говорит браузеру о том, что HTTP сервер выполнил частичный GET запрос клиента (про методы HTTP). Чтобы получить такой код запрос клиента должен содержать поле заголовка Range, который указывает диапазон (вспоминаем диапазоны значений и HTTP параметры).

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

HTTP код состояния 200 (успешно). HTTP код состояния 201 (создано). HTTP код состояния 202 (принято)

HTTP код состояния 200 сообщает о том, что запрос клиента был успешно принят и обработан. Информация, которая будет возвращена пользователю зависит от метода HTTP запроса. Давайте составим небольшую таблицу с методами и тем, какое содержимое им вернет сервер с HTTP кодом состояния 200.

Метод HTTP запроса	Содержимое HTTP ответа с кодом 200
GET	В ответ на метод GET клиент получит HTTP сообщение с кодом 200 и объект, который расположен по указанному URI в запросе (URI в HTTP).
POST	Если клиент отправляет запрос методом POST, то в ответ он получает сообщение с кодом состояния 200 с описание объекта или результатом действия метода POST.
TRACE	Клиент, отправивший запрос методом TRACE, получит HTTP ответ с кодом состояния 200, который будет содержать сообщение, полученное конечным сервером.
HEAD	В ответ на метод HEAD клиент получит сообщение с кодом состояния 200, в котором не будет тела сообщения

HTTP код 200 мы рассмотрели, давайте перейдем к коду 201.

HTTP код состояния 201 сообщает клиенту о том, что запрос успешно выполнен и в результате этого запроса появился новый ресурс по указанному в запросе URI. Но сервер вместо кода 201 может послать код 202 в том случае, если он не может выполнить запрос клиента немедленно. Давайте перейдем к рассмотрению HTTP кода состояния 202.

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

HTTP код состояния 203 (не авторская информация). HTTP код состояния 204 (нет содержимого). HTTP код состояния 205 (сбросить содержимое). HTTP код состояния 206  (частичное содержимое)

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

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

HTTP код состояния 205 говорит браузеру о том, что ему следует (читай требования HTTP) отменить просмотр документа. Такой код состояния HTTP сервера чаще всего используется для очистки форм с целью повторного или последующего ввода и не содержит HTTP объекта.

HTTP код состояния 206 говорит о том, что был выполнен частичный метод GET. Чтобы получить такой код состояния запрос клиента должен содержать поле заголовка Range, в котором указывается диапазон в байтах, при этом ответ HTTP сервера должен содержать поле заголовка Content-Range, либо поле заголовка Content-Type.

Мы рассмотрели успешные коды состояния HTTP, давайте перейдем к кодам перенаправления. Еще есть коды ошибок клиента и коды ошибок сервера, о которых можно узнать на моём сайте. А если тебе нужна информацию обо всех кодах состояния, обратись к справочнику HTTP кодов состояния, в котором есть полное описание всех кодов.

1

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

100 Continue HTTP/1.1

«Продолжай» – сервер принял запрос, клиент может продолжать присылать заголовки.

101 Switching Protocols HTTP/1.1

«Переключение протоколов» – сервер предлагает перейти на другой протокол, список протоколов сервер указывает в заголовке Upgrade.

2

2xx – успешные запросы

200 OK HTTP/1.0

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

201 Created HTTP/1.0

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

202 Accepted HTTP/1.0

«Принято» – запрос был принят, но еще не обработан.

203 Non-Authoritative Information HTTP/1.1

«Информация не авторитетна» – успешный запрос, но передаваемая информация может быть неактуальной.

204 No Content HTTP/1.0

«Нет содержимого» – сервер успешно обработал запрос, но в ответе были переданы только заголовки.

205 Reset Content HTTP/1.1

«Сбросить содержимое» – сервер обязывает сбросить введенные пользователем данные.

206 Partial Content HTTP/1.1

«Частичное содержимое» – сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого.

3

3xx – перенаправления

300 Multiple Choices HTTP/1.0

«Множество выборов» – по запросу существует несколько вариантов ресурса (по MIME, языку и т.д.). Сервер передает список альтернатив, давая клиенту возможность сделать выбор.

301 Moved Permanently HTTP/1.0

«Ресурс перемещен навсегда» – документ был окончательно перенесен на новый URI, указанный в заголовке Location.

301-й редирект в PHP

header('Location: https://exsample.com', true, 301);
exit();

PHP

302 Found HTTP/1.0

«Перемещено временно» – запрошенный документ временно доступен по другому URI, указанному в заголовке Location.

303 See Other HTTP/1.1

«Смотреть другое» – сервер сообщает что документ нужно запросить по адресу переданному в заголовке Location с использованием GET-метода.

Используется для перенаправления после отправки формы методом POST (метод Post/Redirect/Get).

304 Not Modified HTTP/1.0

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

305 Use Proxy HTTP/1.1

«Использовать прокси» – запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в Location.

307 Temporary Redirect HTTP/1.1

«Временное перенаправление» – запрашиваемый ресурс на короткое время доступен по другому URI, указанный в заголовке Location. Метод запроса (GET/POST) менять не разрешается.

308 Permanent Redirect HTTP/1.1

«Постоянное перенаправление» – ресурс был окончательно перенесен на новый URI, указанный в Location. Метод запроса (GET/POST) менять не разрешается.

4

4xx – ошибки клиента

400 Bad Request HTTP/1.0

«Неверный запрос» – запрос не может быть понят сервером из-за некорректного синтаксиса.

401 Unauthorized HTTP/1.1

«Неавторизованный запрос» – для доступа необходимо ввести логин и пароль.

402 Payment Required HTTP/1.1

«Необходима оплата за запрос» – в настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов.

403 Forbidden HTTP/1.0

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

404 Not Found HTTP/1.0

«Ресурс не найден» – документ не существует.

Отправка 404-го кода в PHP

header('HTTP/1.0 404 Not Found');

PHP

405 Method Not Allowed HTTP/1.1

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

406 Not Acceptable HTTP/1.1

«Неприемлемый запрос» – нужный документ существует, но не в том формате (язык или кодировка).

407 Proxy Authentication Required HTTP/1.1

«Требуется идентификация прокси» – ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера.

408 Request Timeout HTTP/1.1

«Время запроса истекло» – клиент не передал полный запрос в течение установленного времени и сервер разорвал соединение.

409 Conflict HTTP/1.1

«Конфликт» – запрос конфликтует с другим запросом или с конфигурацией сервера. Например, такое возможно когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone HTTP/1.1

«Недоступен» – такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был окончательно удален с сайта. Если документ в ближайшее время может быть восстановлен, то лучше передать 404-й код.

411 Length Required HTTP/1.1

«Необходимо указать длину» – сервер отказывается принимать запрос без заголовка Content-Length. Такой ответ естественен для запросов типа POST и PUT.

412 Precondition Failed HTTP/1.1

«Условие ложно» – при проверке на сервере одного или более заголовков обнаружено несоответствие.

413 Payload Too Large HTTP/1.1

«Тело запроса превышает допустимый размер» – сервер отказывается обрабатывать запрос из-за слишком большого размера тела.

414 URI Too Long HTTP/1.1

«Недопустимая длина URI запроса» – сервер не может обработать запрос из-за слишком длинного URI.

415 Unsupported Media Type HTTP/1.1

«Неподдерживаемый MIME» – сервер отказывается работать с указанным типом данных.

416 Range Not Satisfiable HTTP/1.1

«Диапазон не может быть обработан» – в заголовке Range был указан недопустимый диапазон байтов.

417 Expectation Failed HTTP/1.1

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

426 Upgrade Required

«Требуется обновление» – сервер отказывается выполнять запрос с использованием текущего протокола. Введено в для возможности перехода к TLS.

5

5xx – ошибки сервера

500 Internal Server Error HTTP/1.0

Внутренняя ошибка сервера. Обычно возникает из-за ошибок в файле .htaccess или критической ошибки PHP при отключенном показе ошибок.

Включить показ ошибок PHP

error_reporting(E_ALL);
ini_set('display_errors', 1); 

PHP

501 Not Implemented HTTP/1.0

«Не реализовано» – сервер не имеет возможностей для обработки запроса.

502 Bad Gateway HTTP/1.0

«Плохой, ошибочный шлюз» – сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера.

503 Service Unavailable HTTP/1.0

«Сервис недоступен» – сервер временно не может обрабатывать запросы по техническим причинам. В заголовке Retry-After указывается время, через которое клиенту рекомендуется повторить запрос.

504 Gateway Timeout HTTP/1.1

«Шлюз не отвечает» – сервер в роли прокси-сервера не дождался ответа от вышестоящего сервера.

505 HTTP Version Not Supported HTTP/1.1

«Версия HTTP не поддерживается» – сервер не поддерживает предлагаемую версию протокола HTTP.

Содержание

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

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

В браузере

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

В Google Search Console

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

100 Continue

101 Switching Protocols

102 Processing

103 Checkpoint

105 Name Not Resolved

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

200 ОК

201 Created

202 Accepted

203 Non‑Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi‑Status

226 IM Used

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

300 Multiple Choices

301 Moved Permanently

302 Found/Moved 

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Resume Incomplete

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

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request‑URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot

422 Unprocessable Entity

423 Locked

424 Failed Dependency

425 Unordered Collection

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

434 Requested Host Unavailable

444 No Response

449 Retry With

450 Blocked by Windows Parental Controls

451 Unavailable For Legal Reasons

456 Unrecoverable Error

499 Client Closed Request

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

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

509 Bandwidth Limit Exceeded

510 Not Extended

511 Network Authentication Required

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

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

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

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

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

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

В браузере

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

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

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

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

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

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

В Google Search Console

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

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

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

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

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

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

100 Continue

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

101 Switching Protocols

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

102 Processing

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

103 Checkpoint

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

105 Name Not Resolved

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

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

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

200 ОК

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

201 Created

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

202 Accepted

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

203 Non‑Authoritative Information

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

204 No Content

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

205 Reset Content

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

206 Partial Content

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

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

207 Multi‑Status

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

226 IM Used

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

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

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

300 Multiple Choices

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

301 Moved Permanently

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

302 Found/Moved 

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

303 See Other

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

304 Not Modified

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

305 Use Proxy

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

306 Unused

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

307 Temporary Redirect

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

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

308 Resume Incomplete

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

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

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

400 Bad Request

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

401 Unauthorized

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

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

402 Payment Required

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

403 Forbidden

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

404 Not Found

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

405 Method Not Allowed

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

406 Not Acceptable

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

407 Proxy Authentication Required

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

408 Request Timeout

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

409 Conflict

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

410 Gone

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

411 Length Required

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

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

412 Precondition Failed

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

413 Request Entity Too Large

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

414 Request‑URI Too Long

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

415 Unsupported Media Type

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

416 Requested Range Not Satisfiable

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

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

417 Expectation Failed

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

418 I’m a teapot

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

422 Unprocessable Entity

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

423 Locked

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

424 Failed Dependency

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

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

425 Unordered Collection

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

426 Upgrade Required

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

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

428 Precondition Required

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

429 Too Many Requests

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

431 Request Header Fields Too Large

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

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

434 Requested Host Unavailable

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

444 No Response

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

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

449 Retry With

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

450 Blocked by Windows Parental Controls

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

451 Unavailable For Legal Reasons

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

456 Unrecoverable Error

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

499 Client Closed Request

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

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

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

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

500 Internal Server Error

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

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

501 Not Implemented

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

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

502 Bad Gateway

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

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

503 Service Unavailable

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

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

504 Gateway Timeout

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

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

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

505 HTTP Version Not Supported

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

506 Variant Also Negotiates

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

507 Insufficient Storage

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

508 Loop Detected

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

509 Bandwidth Limit Exceeded

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

510 Not Extended

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

511 Network Authentication Required

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

Во время запроса информации с удаленного веб-сервера может возникнуть ошибка. Тогда веб-сервер посылает в ответ код ошибки HTTP. Например 404 — Not Found (ресурс не найден).

Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

1. Информационные (100-105).
2. Успешные (200-226).
3. Перенаправление (300-307).
4. Ошибка клиента (400-499).
5. Ошибка сервера (500-510).

Чтобы получить сведения об ошибке, введите её код в поле поиска по странице. Для этого нажмите сочетание клавиш CTRL + F и укажите номер.

100

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

101

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

102

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

200

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

201

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

202

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

203

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

204

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

205

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

206

Partial Content
Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)

207

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

226

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

300

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

301

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

302

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

303

See Other
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304

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

305

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

306

(зарезервировано)
использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307

Temporary Redirect
Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

400

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

401

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

402

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

403

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

404

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

405

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

406

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

407

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

408

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

409

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

410

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

411

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

412

Precondition Failed
Возвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

413

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

414

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

415

Unsupported Media Type
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416

Requested Range Not Satisfiabl
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

417

Expectation Failed
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

422

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

423

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

424

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

425

Unordered Collection —
Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol[14].

426

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

449

Retry With
Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

456

Unrecoverable Error
Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

500

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

501

Not Implemented
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502

Bad Gateway
Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503

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

504

Gateway Timeout
Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505

HTTP Version Not Supported
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506

Variant Also Negotiates
В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507

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

509

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

510

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

REST APIs use the Status-Line part of an HTTP response message to inform clients of their request’s overarching result. RFC 2616 defines the Status-Line syntax as shown below:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP defines these standard status codes that can be used to convey the results of a client’s request. The status codes are divided into five categories.

• 1xx: Informational – Communicates transfer protocol-level information.
• 2xx: Success – Indicates that the client’s request was accepted successfully.
• 3xx: Redirection – Indicates that the client must take some additional action in order to complete their request.
• 4xx: Client Error – This category of error status codes points the finger at clients.
• 5xx: Server Error – The server takes responsibility for these error status codes.

1xx Status Codes [Informational]

Status Code	Description
100 Continue	An interim response. Indicates to the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.
101 Switching Protocol	Sent in response to an Upgrade request header from the client, and indicates the protocol the server is switching to.
102 Processing (WebDAV)	Indicates that the server has received and is processing the request, but no response is available yet.
103 Early Hints	Primarily intended to be used with the Link header. It suggests the user agent start preloading the resources while the server prepares a final response.

2xx Status Codes [Success]

Status Code	Description
200 OK	Indicates that the request has succeeded.
201 Created	Indicates that the request has succeeded and a new resource has been created as a result.
202 Accepted	Indicates that the request has been received but not completed yet. It is typically used in log running requests and batch processing.
203 Non-Authoritative Information	Indicates that the returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version.
204 No Content	The server has fulfilled the request but does not need to return a response body. The server may return the updated meta information.
205 Reset Content	Indicates the client to reset the document which sent this request.
206 Partial Content	It is used when the Range header is sent from the client to request only part of a resource.
207 Multi-Status (WebDAV)	An indicator to a client that multiple operations happened, and that the status for each operation can be found in the body of the response.
208 Already Reported (WebDAV)	Allows a client to tell the server that the same resource (with the same binding) was mentioned earlier. It never appears as a true HTTP response code in the status line, and only appears in bodies.
226 IM Used	The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

3xx Status Codes [Redirection]

Status Code	Description
300 Multiple Choices	The request has more than one possible response. The user-agent or user should choose one of them.
301 Moved Permanently	The URL of the requested resource has been changed permanently. The new URL is given by the Location header field in the response. This response is cacheable unless indicated otherwise.
302 Found	The URL of the requested resource has been changed temporarily. The new URL is given by the Location field in the response. This response is only cacheable if indicated by a Cache-Control or Expires header field.
303 See Other	The response can be found under a different URI and SHOULD be retrieved using a GET method on that resource.
304 Not Modified	Indicates the client that the response has not been modified, so the client can continue to use the same cached version of the response.
305 Use Proxy (Deprecated)	Indicates that a requested response must be accessed by a proxy.
306 (Unused)	It is a reserved status code and is not used anymore.
307 Temporary Redirect	Indicates the client to get the requested resource at another URI with same method that was used in the prior request. It is similar to 302 Found with one exception that the same HTTP method will be used that was used in the prior request.
308 Permanent Redirect (experimental)	Indicates that the resource is now permanently located at another URI, specified by the Location header. It is similar to 301 Moved Permanently with one exception that the same HTTP method will be used that was used in the prior request.

4xx Status Codes (Client Error)

Status Code	Description
400 Bad Request	The request could not be understood by the server due to incorrect syntax. The client SHOULD NOT repeat the request without modifications.
401 Unauthorized	Indicates that the request requires user authentication information. The client MAY repeat the request with a suitable Authorization header field
402 Payment Required (Experimental)	Reserved for future use. It is aimed for using in the digital payment systems.
403 Forbidden	Unauthorized request. The client does not have access rights to the content. Unlike 401, the client’s identity is known to the server.
404 Not Found	The server can not find the requested resource.
405 Method Not Allowed	The request HTTP method is known by the server but has been disabled and cannot be used for that resource.
406 Not Acceptable	The server doesn’t find any content that conforms to the criteria given by the user agent in the Accept header sent in the request.
407 Proxy Authentication Required	Indicates that the client must first authenticate itself with the proxy.
408 Request Timeout	Indicates that the server did not receive a complete request from the client within the server’s allotted timeout period.
409 Conflict	The request could not be completed due to a conflict with the current state of the resource.
410 Gone	The requested resource is no longer available at the server.
411 Length Required	The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field.
412 Precondition Failed	The client has indicated preconditions in its headers which the server does not meet.
413 Request Entity Too Large	Request entity is larger than limits defined by server.
414 Request-URI Too Long	The URI requested by the client is longer than the server can interpret.
415 Unsupported Media Type	The media-type in Content-type of the request is not supported by the server.
416 Requested Range Not Satisfiable	The range specified by the Range header field in the request can’t be fulfilled.
417 Expectation Failed	The expectation indicated by the Expect request header field can’t be met by the server.
418 I’m a teapot (RFC 2324)	It was defined as April’s lool joke and is not expected to be implemented by actual HTTP servers. (RFC 2324)
420 Enhance Your Calm (Twitter)	Returned by the Twitter Search and Trends API when the client is being rate limited.
422 Unprocessable Entity (WebDAV)	The server understands the content type and syntax of the request entity, but still server is unable to process the request for some reason.
423 Locked (WebDAV)	The resource that is being accessed is locked.
424 Failed Dependency (WebDAV)	The request failed due to failure of a previous request.
425 Too Early (WebDAV)	Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required	The server refuses to perform the request. The server will process the request after the client upgrades to a different protocol.
428 Precondition Required	The origin server requires the request to be conditional.
429 Too Many Requests	The user has sent too many requests in a given amount of time (“rate limiting”).
431 Request Header Fields Too Large	The server is unwilling to process the request because its header fields are too large.
444 No Response (Nginx)	The Nginx server returns no information to the client and closes the connection.
449 Retry With (Microsoft)	The request should be retried after performing the appropriate action.
450 Blocked by Windows Parental Controls (Microsoft)	Windows Parental Controls are turned on and are blocking access to the given webpage.
451 Unavailable For Legal Reasons	The user-agent requested a resource that cannot legally be provided.
499 Client Closed Request (Nginx)	The connection is closed by the client while HTTP server is processing its request, making the server unable to send the HTTP header back.

5xx Status Codes (Server Error)

Status Code	Description
500 Internal Server Error	The server encountered an unexpected condition that prevented it from fulfilling the request.
501 Not Implemented	The HTTP method is not supported by the server and cannot be handled.
502 Bad Gateway	The server got an invalid response while working as a gateway to get the response needed to handle the request.
503 Service Unavailable	The server is not ready to handle the request.
504 Gateway Timeout	The server is acting as a gateway and cannot get a response in time for a request.
505 HTTP Version Not Supported (Experimental)	The HTTP version used in the request is not supported by the server.
506 Variant Also Negotiates (Experimental)	Indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper endpoint in the negotiation process.
507 Insufficient Storage (WebDAV)	The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.
508 Loop Detected (WebDAV)	The server detected an infinite loop while processing the request.
510 Not Extended	Further extensions to the request are required for the server to fulfill it.
511 Network Authentication Required	Indicates that the client needs to authenticate to gain network access.

6. REST Specific HTTP Status Codes

200 (OK)

It indicates that the REST API successfully carried out whatever action the client requested and that no more specific code in the 2xx series is appropriate.

Unlike the 204 status code, a 200 response should include a response body. The information returned with the response is dependent on the method used in the request, for example:

• GET an entity corresponding to the requested resource is sent in the response;
• HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
• POST an entity describing or containing the result of the action;
• TRACE an entity containing the request message as received by the end server.

201 (Created)

A REST API responds with the 201 status code whenever a resource is created inside a collection. There may also be times when a new resource is created as a result of some controller action, in which case 201 would also be an appropriate response.

The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.

The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with a 202 (Accepted) response instead.

202 (Accepted)

A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.

Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed.

The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor (job queue location) or some estimate of when the user can expect the request to be fulfilled.

204 (No Content)

The 204 status code is usually sent out in response to a PUT, POST, or DELETE request when the REST API declines to send back any status message or representation in the response message’s body.

An API may also send 204 in conjunction with a GET request to indicate that the requested resource exists, but has no state representation to include in the body.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view. However, any new or updated metainformation SHOULD be applied to the document currently in the user agent’s dynamic view.

The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields.

301 (Moved Permanently)

The 301 status code indicates that the REST API’s resource model has been significantly redesigned, and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header, and all future requests should be directed to the given URI.

You will hardly use this response code in your API as you can always use the API versioning for the new API while retaining the old one.

302 (Found)

The HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the Location header field. The user agent (e.g., a web browser) is invited by a response with this code to make a second. Otherwise identical, request to the new URL specified in the location field.

Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g., POST). RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

303 (See Other)

A 303 response indicates that a controller resource has finished its work, but instead of sending a potentially unwanted response body, it sends the client the URI of a response resource. The response can be the URI of the temporary status message, or the URI to some already existing, more permanent, resource.

Generally speaking, the 303 status code allows a REST API to send a reference to a resource without forcing the client to download its state. Instead, the client may send a GET request to the value of the Location header.

The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

304 (Not Modified)

This status code is similar to 204 (“No Content”) in that the response body must be empty. The critical distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.

In such a case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.

Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.

307 (Temporary Redirect)

A 307 response indicates that the REST API is not going to process the client’s request. Instead, the client should resubmit the request to the URI specified by the response message’s Location header. However, future requests should still use the original URI.

A REST API can use this status code to assign a temporary URI to the client’s requested resource. For example, a 307 response can be used to shift a client request over to another host.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

400 (Bad Request)

400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.

The client SHOULD NOT repeat the request without modifications.

401 (Unauthorized)

A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information.

403 (Forbidden)

A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it, i.e., the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”).

Authentication will not help, and the request SHOULD NOT be repeated. Unlike a 401 Unauthorized response, authenticating will make no difference.

404 (Not Found)

The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.

No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

405 (Method Not Allowed)

The API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.

A 405 response must include the Allow header, which lists the HTTP methods that the resource supports. For example:

Allow: GET, POST

406 (Not Acceptable)

The 406 error response indicates that the API is not able to generate any of the client’s preferred media types, as indicated by the Accept request header. For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

412 (Precondition Failed)

The 412 error response indicates that the client specified one or more preconditions in its request headers, effectively telling the REST API to carry out its request only if certain conditions were met. A 412 response indicates that those conditions were not met, so instead of carrying out the request, the API sends this status code.

415 (Unsupported Media Type)

The 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json.

For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

500 (Internal Server Error)

500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.

A 500 error is never the client’s fault, and therefore, it is reasonable for the client to retry the same request that triggered this response and hope to get a different response.

The API response is the 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 cannot fulfill the request. Usually, this implies future availability (e.g., a new feature of a web-service API).

References :

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml