Ошибка 303 http - Исправление ошибок и поиск оптимальных решений проблем

From Wikipedia, the free encyclopedia

The HTTP response status code 303 See Other is a way to redirect web applications to a new URI, particularly after a HTTP POST has been performed, since RFC 2616 (HTTP 1.1).

According to RFC 7231, which obsoletes RFC 2616, «A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource.»

This status code should be used with the location header, as described below. If a server responds to a POST or other non-idempotent request with a 303 See Other response and a value for the location header, the client is expected to obtain the resource mentioned in the location header using the GET method; to trigger a request to the target resource using the same method, the server is expected to provide a 307 Temporary Redirect response.

303 See Other has been proposed as one way of responding to a request for a URI that identifies a real-world object according to Semantic Web theory (the other being the use of hash URIs).^[1] For example, if http://www.example.com/id/alice identifies a person, Alice, then it would be inappropriate for a server to respond to a GET request with 200 OK, as the server could not deliver Alice herself. Instead the server would issue a 303 See Other response which redirected to a separate URI providing a description of the person Alice.

303 See Other can be used for other purposes. For example, when building a RESTful web API that needs to return to the caller immediately but continue executing asynchronously (such as a long-lived image conversion), the web API can provide a status check URI that allows the original client who requested the conversion to check on the conversion’s status. This status check web API should return 303 See Other to the caller when the task is complete, along with a URI from which to retrieve the result in the Location HTTP header field.^[2]

Example[edit]

Client request:

POST / HTTP/1.1
Host: www.example.com

Server response:

HTTP/1.1 303 See Other
Location: http://example.org/other

References[edit]

^ «Cool URIs for the Semantic Web: Hash URIs». W3C Interest Group Note. 2008-12-03.
^ Allamaraju, Subbu; Allamaraju, Subrahmanyam (March 2010). RESTful Web Services Cookbook. O’Reilly Media. ISBN 9780596801687.

Источник

From Wikipedia, the free encyclopedia

(Redirected from 202 Accepted)

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

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

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

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

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

1xx informational response

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

100 Continue: The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]
101 Switching Protocols: The requester has asked the server to switch protocols and the server has agreed to do so.
102 Processing (WebDAV; RFC 2518): A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.
103 Early Hints (RFC 8297): Used to return some response headers before final HTTP message.^[4]

2xx success

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

200 OK: Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
201 Created: The request has been fulfilled, resulting in the creation of a new resource.^[5]
202 Accepted: The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
203 Non-Authoritative Information (since HTTP/1.1): The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6]^[7]
204 No Content: The server successfully processed the request, and is not returning any content.
205 Reset Content: The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.
206 Partial Content: The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
207 Multi-Status (WebDAV; RFC 4918): The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]
208 Already Reported (WebDAV; RFC 5842): The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.
226 IM Used (RFC 3229): The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[9]

3xx redirection

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

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

300 Multiple Choices: Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.
301 Moved Permanently: This and all future requests should be directed to the given URI.
302 Found (Previously «Moved temporarily»): Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]
303 See Other (since HTTP/1.1): The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.
304 Not Modified: Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
305 Use Proxy (since HTTP/1.1): The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.
306 Switch Proxy: No longer used. Originally meant «Subsequent requests should use the specified proxy.»
307 Temporary Redirect (since HTTP/1.1): In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.
308 Permanent Redirect: This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

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

400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.; Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}
402 Payment Required: Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]
403 Forbidden: The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.
404 Not Found: The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
405 Method Not Allowed: A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.
406 Not Acceptable: The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.
407 Proxy Authentication Required: The client must first authenticate itself with the proxy.
408 Request Timeout: The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»
409 Conflict: Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.
410 Gone: Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.
411 Length Required: The request did not specify the length of its content, which is required by the requested resource.
412 Precondition Failed: The server does not meet one of the preconditions that the requester put on the request header fields.
413 Payload Too Large: The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]
414 URI Too Long: The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]
415 Unsupported Media Type: The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Range Not Satisfiable: The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field.^[21]
418 I’m a teapot (RFC 2324, RFC 7168): This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23]^[24]^[25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26]^[27]
421 Misdirected Request: The request was directed at a server that is not able to produce a response (for example because of connection reuse).
422 Unprocessable Entity: The request was well-formed but was unable to be followed due to semantic errors.^[8]
423 Locked (WebDAV; RFC 4918): The resource that is being accessed is locked.^[8]
424 Failed Dependency (WebDAV; RFC 4918): The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]
425 Too Early (RFC 8470): Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required: The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.
428 Precondition Required (RFC 6585): The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.^[28]
429 Too Many Requests (RFC 6585): The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]
431 Request Header Fields Too Large (RFC 6585): The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]
451 Unavailable For Legal Reasons (RFC 7725): A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

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

500 Internal Server Error: A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501 Not Implemented: The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable: The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]
504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505 HTTP Version Not Supported: The server does not support the HTTP version used in the request.
506 Variant Also Negotiates (RFC 2295): Transparent content negotiation for the request results in a circular reference.^[31]
507 Insufficient Storage (WebDAV; RFC 4918): The server is unable to store the representation needed to complete the request.^[8]
508 Loop Detected (WebDAV; RFC 5842): The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).
510 Not Extended (RFC 2774): Further extensions to the request are required for the server to fulfill it.^[32]
511 Network Authentication Required (RFC 6585): The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework): Used by the Laravel Framework when a CSRF Token is missing or expired.
420 Method Failure (Spring Framework): A deprecated response used by the Spring Framework when a method has failed.^[33]
420 Enhance Your Calm (Twitter): Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}
430 Request Header Fields Too Large (Shopify): Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]
450 Blocked by Windows Parental Controls (Microsoft): The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]
498 Invalid Token (Esri): Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]
499 Token Required (Esri): Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel): The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]
529 Site is overloaded: Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]
530 Site is frozen: Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]
598 (Informal convention) Network read timeout error: Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]
599 Network Connect Timeout Error: An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

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

440 Login Time-out: The client’s session has expired and must log in again.^[42]
449 Retry With: The server cannot honour the request because the user has not provided the required information.^[43]
451 Redirect: Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

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

nginx

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

444 No Response: Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.
494 Request header too large: Client sent too large request or too long header line.
495 SSL Certificate Error: An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.
496 SSL Certificate Required: An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.
497 HTTP Request Sent to HTTPS Port: An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.
499 Client Closed Request: Used when the client has closed the request before the server could send a response.

Cloudflare

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

520 Web Server Returned an Unknown Error: The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]
521 Web Server Is Down: The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.
522 Connection Timed Out: Cloudflare timed out contacting the origin server.
523 Origin Is Unreachable: Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.
524 A Timeout Occurred: Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.
525 SSL Handshake Failed: Cloudflare could not negotiate a SSL/TLS handshake with the origin server.
526 Invalid SSL Certificate: Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.
527 Railgun Error: Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]
530: Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

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

460: Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]
463: The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]
561 Unauthorized: An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

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

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

110 Response is Stale: The response provided by a cache is stale (the content’s age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).
111 Revalidation Failed: The cache was unable to validate the response, due to an inability to reach the origin server.
112 Disconnected Operation: The cache is intentionally disconnected from the rest of the network.
113 Heuristic Expiration: The cache heuristically chose a freshness lifetime greater than 24 hours and the response’s age is greater than 24 hours.
199 Miscellaneous Warning: Arbitrary, non-specific warning. The warning text may be logged or presented to the user.
214 Transformation Applied: Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.
299 Miscellaneous Persistent Warning: Same as 199, but indicating a persistent warning.

Explanatory notes

^ Emphasised words and phrases such as must and should represent interpretation guidelines as given by RFC 2119

References

^ ^a ^b ^c «Hypertext Transfer Protocol (HTTP) Status Code Registry». Iana.org. Archived from the original on December 11, 2011. Retrieved January 8, 2015.
^ «RFC 9110: HTTP Semantics and Content, Section 10.1.1 «Expect»«.
^ Goland, Yaronn; Whitehead, Jim; Faizi, Asad; Carter, Steve R.; Jensen, Del (February 1999). HTTP Extensions for Distributed Authoring – WEBDAV. IETF. doi:10.17487/RFC2518. RFC 2518. Retrieved October 24, 2009.
^ Oku, Kazuho (December 2017). An HTTP Status Code for Indicating Hints. IETF. doi:10.17487/RFC8297. RFC 8297. Retrieved December 20, 2017.
^ Stewart, Mark; djna. «Create request with POST, which response codes 200 or 201 and content». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
^ «RFC 9110: HTTP Semantics and Content, Section 15.3.4».
^ «RFC 9110: HTTP Semantics and Content, Section 7.7».
^ ^a ^b ^c ^d ^e Dusseault, Lisa, ed. (June 2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF. doi:10.17487/RFC4918. RFC 4918. Retrieved October 24, 2009.
^ Delta encoding in HTTP. IETF. January 2002. doi:10.17487/RFC3229. RFC 3229. Retrieved February 25, 2011.
^ ^a ^b «RFC 9110: HTTP Semantics and Content, Section 15.4 «Redirection 3xx»«.
^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk (May 1996). Hypertext Transfer Protocol – HTTP/1.0. IETF. doi:10.17487/RFC1945. RFC 1945. Retrieved October 24, 2009.
^ «The GNU Taler tutorial for PHP Web shop developers 0.4.0». docs.taler.net. Archived from the original on November 8, 2017. Retrieved October 29, 2017.
^ «Google API Standard Error Responses». 2016. Archived from the original on May 25, 2017. Retrieved June 21, 2017.
^ «Sipgate API Documentation». Archived from the original on July 10, 2018. Retrieved July 10, 2018.
^ «Shopify Documentation». Archived from the original on July 25, 2018. Retrieved July 25, 2018.
^ «Stripe API Reference – Errors». stripe.com. Retrieved October 28, 2019.
^ «RFC2616 on status 413». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ «RFC2616 on status 414». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ «RFC2616 on status 416». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ TheDeadLike. «HTTP/1.1 Status Codes 400 and 417, cannot choose which». serverFault. Archived from the original on October 10, 2015. Retrieved October 16, 2015.
^ Larry Masinter (April 1, 1998). Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). doi:10.17487/RFC2324. RFC 2324. Any attempt to brew coffee with a teapot should result in the error code «418 I’m a teapot». The resulting entity body MAY be short and stout.
^ I’m a teapot
^ Barry Schwartz (August 26, 2014). «New Google Easter Egg For SEO Geeks: Server Status 418, I’m A Teapot». Search Engine Land. Archived from the original on November 15, 2015. Retrieved November 4, 2015.
^ «Google’s Teapot». Retrieved October 23, 2017.^{[dead link]}
^ «Enable extra web security on a website». DreamHost. Retrieved December 18, 2022.
^ «I Went to a Russian Website and All I Got Was This Lousy Teapot». PCMag. Retrieved December 18, 2022.
^ ^a ^b ^c ^d Nottingham, M.; Fielding, R. (April 2012). «RFC 6585 – Additional HTTP Status Codes». Request for Comments. Internet Engineering Task Force. Archived from the original on May 4, 2012. Retrieved May 1, 2012.
^ Bray, T. (February 2016). «An HTTP Status Code to Report Legal Obstacles». ietf.org. Archived from the original on March 4, 2016. Retrieved March 7, 2015.
^ alex. «What is the correct HTTP status code to send when a site is down for maintenance?». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
^ Holtman, Koen; Mutz, Andrew H. (March 1998). Transparent Content Negotiation in HTTP. IETF. doi:10.17487/RFC2295. RFC 2295. Retrieved October 24, 2009.
^ Nielsen, Henrik Frystyk; Leach, Paul; Lawrence, Scott (February 2000). An HTTP Extension Framework. IETF. doi:10.17487/RFC2774. RFC 2774. Retrieved October 24, 2009.
^ «Enum HttpStatus». Spring Framework. org.springframework.http. Archived from the original on October 25, 2015. Retrieved October 16, 2015.
^ «Twitter Error Codes & Responses». Twitter. 2014. Archived from the original on September 27, 2017. Retrieved January 20, 2014.
^ «HTTP Status Codes and SEO: what you need to know». ContentKing. Retrieved August 9, 2019.
^ «Screenshot of error page». Archived from the original (bmp) on May 11, 2013. Retrieved October 11, 2009.
^ ^a ^b «Using token-based authentication». ArcGIS Server SOAP SDK. Archived from the original on September 26, 2014. Retrieved September 8, 2014.
^ «HTTP Error Codes and Quick Fixes». Docs.cpanel.net. Archived from the original on November 23, 2015. Retrieved October 15, 2015.
^ «SSL Labs API v3 Documentation». github.com.
^ «Platform Considerations | Pantheon Docs». pantheon.io. Archived from the original on January 6, 2017. Retrieved January 5, 2017.
^ «HTTP status codes — ascii-code.com». www.ascii-code.com. Archived from the original on January 7, 2017. Retrieved December 23, 2016.
^
«Error message when you try to log on to Exchange 2007 by using Outlook Web Access: «440 Login Time-out»«. Microsoft. 2010. Retrieved November 13, 2013.
^ «2.2.6 449 Retry With Status Code». Microsoft. 2009. Archived from the original on October 5, 2009. Retrieved October 26, 2009.
^ «MS-ASCMD, Section 3.1.5.2.2». Msdn.microsoft.com. Archived from the original on March 26, 2015. Retrieved January 8, 2015.
^ «Ms-oxdisco». Msdn.microsoft.com. Archived from the original on July 31, 2014. Retrieved January 8, 2015.
^ «The HTTP status codes in IIS 7.0». Microsoft. July 14, 2009. Archived from the original on April 9, 2009. Retrieved April 1, 2009.
^ «ngx_http_request.h». nginx 1.9.5 source code. nginx inc. Archived from the original on September 19, 2017. Retrieved January 9, 2016.
^ «ngx_http_special_response.c». nginx 1.9.5 source code. nginx inc. Archived from the original on May 8, 2018. Retrieved January 9, 2016.
^ «return» directive Archived March 1, 2018, at the Wayback Machine (http_rewrite module) documentation.
^ «Troubleshooting: Error Pages». Cloudflare. Archived from the original on March 4, 2016. Retrieved January 9, 2016.
^ «Error 520: web server returns an unknown error». Cloudflare. Retrieved November 1, 2019.
^ «527 Error: Railgun Listener to origin error». Cloudflare. Archived from the original on October 13, 2016. Retrieved October 12, 2016.
^ «Error 530». Cloudflare. Retrieved November 1, 2019.
^ ^a ^b «Troubleshoot Your Application Load Balancers – Elastic Load Balancing». docs.aws.amazon.com. Retrieved August 27, 2019.
^ «Troubleshoot your Application Load Balancers — Elastic Load Balancing». docs.aws.amazon.com. Retrieved January 24, 2021.
^ «Hypertext Transfer Protocol (HTTP/1.1): Caching». datatracker.ietf.org. Retrieved September 25, 2021.
^ «Warning — HTTP | MDN». developer.mozilla.org. Retrieved August 15, 2021. Some text was copied from this source, which is available under a Creative Commons Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5) license.
^ «RFC 9111: HTTP Caching, Section 5.5 «Warning»«. June 2022.

External links

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

Источник

From Wikipedia, the free encyclopedia

(Redirected from 202 Accepted)

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]

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

100 Continue: The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request’s headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request’s body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers).^[2]
101 Switching Protocols: The requester has asked the server to switch protocols and the server has agreed to do so.
102 Processing (WebDAV; RFC 2518): A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.^[3] This prevents the client from timing out and assuming the request was lost.
103 Early Hints (RFC 8297): Used to return some response headers before final HTTP message.^[4]

2xx success

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

200 OK: Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
201 Created: The request has been fulfilled, resulting in the creation of a new resource.^[5]
202 Accepted: The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
203 Non-Authoritative Information (since HTTP/1.1): The server is a transforming proxy (e.g. a Web accelerator) that received a 200 OK from its origin, but is returning a modified version of the origin’s response.^[6]^[7]
204 No Content: The server successfully processed the request, and is not returning any content.
205 Reset Content: The server successfully processed the request, asks that the requester reset its document view, and is not returning any content.
206 Partial Content: The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
207 Multi-Status (WebDAV; RFC 4918): The message body that follows is by default an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.^[8]
208 Already Reported (WebDAV; RFC 5842): The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again.
226 IM Used (RFC 3229): The server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.^[9]

3xx redirection

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

300 Multiple Choices: Indicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.
301 Moved Permanently: This and all future requests should be directed to the given URI.
302 Found (Previously «Moved temporarily»): Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was «Moved Temporarily»),^[11] but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.^[10]
303 See Other (since HTTP/1.1): The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.
304 Not Modified: Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
305 Use Proxy (since HTTP/1.1): The requested resource is available only through a proxy, the address for which is provided in the response. For security reasons, many HTTP clients (such as Mozilla Firefox and Internet Explorer) do not obey this status code.
306 Switch Proxy: No longer used. Originally meant «Subsequent requests should use the specified proxy.»
307 Temporary Redirect (since HTTP/1.1): In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.
308 Permanent Redirect: This and all future requests should be directed to the given URI. 308 parallel the behaviour of 301, but does not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.

4xx client errors

400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means «unauthorised», the user does not have valid authentication credentials for the target resource.; Some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.^{[citation needed]}
402 Payment Required: Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, for example, by GNU Taler,^[13] but that has not yet happened, and this code is not widely used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.^[14] Sipgate uses this code if an account does not have sufficient funds to start a call.^[15] Shopify uses this code when the store has not paid their fees and is temporarily disabled.^[16] Stripe uses this code for failed payments where parameters were correct, for example blocked fraudulent payments.^[17]
403 Forbidden: The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.
404 Not Found: The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
405 Method Not Allowed: A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via POST, or a PUT request on a read-only resource.
406 Not Acceptable: The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See Content negotiation.
407 Proxy Authentication Required: The client must first authenticate itself with the proxy.
408 Request Timeout: The server timed out waiting for the request. According to HTTP specifications: «The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.»
409 Conflict: Indicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.
410 Gone: Indicates that the resource requested was previously in use but is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a «404 Not Found» may be used instead.
411 Length Required: The request did not specify the length of its content, which is required by the requested resource.
412 Precondition Failed: The server does not meet one of the preconditions that the requester put on the request header fields.
413 Payload Too Large: The request is larger than the server is willing or able to process. Previously called «Request Entity Too Large» in RFC 2616.^[18]
414 URI Too Long: The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called «Request-URI Too Long» previously in RFC 2616.^[19]
415 Unsupported Media Type: The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Range Not Satisfiable: The client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called «Requested Range Not Satisfiable» previously RFC 2616.^[20]
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field.^[21]
418 I’m a teapot (RFC 2324, RFC 7168): This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.^[22] This HTTP status is used as an Easter egg in some websites, such as Google.com’s «I’m a teapot» easter egg.^[23]^[24]^[25] Sometimes, this status code is also used as a response to a blocked request, instead of the more appropriate 403 Forbidden.^[26]^[27]
421 Misdirected Request: The request was directed at a server that is not able to produce a response (for example because of connection reuse).
422 Unprocessable Entity: The request was well-formed but was unable to be followed due to semantic errors.^[8]
423 Locked (WebDAV; RFC 4918): The resource that is being accessed is locked.^[8]
424 Failed Dependency (WebDAV; RFC 4918): The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).^[8]
425 Too Early (RFC 8470): Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required: The client should switch to a different protocol such as TLS/1.3, given in the Upgrade header field.
428 Precondition Required (RFC 6585): The origin server requires the request to be conditional. Intended to prevent the ‘lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.^[28]
429 Too Many Requests (RFC 6585): The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.^[28]
431 Request Header Fields Too Large (RFC 6585): The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.^[28]
451 Unavailable For Legal Reasons (RFC 7725): A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.^[29] The code 451 was chosen as a reference to the novel Fahrenheit 451 (see the Acknowledgements in the RFC).

5xx server errors

The server failed to fulfil a request.

500 Internal Server Error: A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501 Not Implemented: The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable: The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.^[30]
504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505 HTTP Version Not Supported: The server does not support the HTTP version used in the request.
506 Variant Also Negotiates (RFC 2295): Transparent content negotiation for the request results in a circular reference.^[31]
507 Insufficient Storage (WebDAV; RFC 4918): The server is unable to store the representation needed to complete the request.^[8]
508 Loop Detected (WebDAV; RFC 5842): The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).
510 Not Extended (RFC 2774): Further extensions to the request are required for the server to fulfill it.^[32]
511 Network Authentication Required (RFC 6585): The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., «captive portals» used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).^[28]

Unofficial codes

The following codes are not specified by any standard.

419 Page Expired (Laravel Framework): Used by the Laravel Framework when a CSRF Token is missing or expired.
420 Method Failure (Spring Framework): A deprecated response used by the Spring Framework when a method has failed.^[33]
420 Enhance Your Calm (Twitter): Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.^[34] The phrase «Enhance your calm» comes from the 1993 movie Demolition Man, and its association with this number is likely a reference to cannabis.^{[citation needed]}
430 Request Header Fields Too Large (Shopify): Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.^[35]
450 Blocked by Windows Parental Controls (Microsoft): The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.^[36]
498 Invalid Token (Esri): Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.^[37]
499 Token Required (Esri): Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.^[37]
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel): The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.^[38]
529 Site is overloaded: Used by Qualys in the SSLLabs server testing API to signal that the site can’t process the request.^[39]
530 Site is frozen: Used by the Pantheon Systems web platform to indicate a site that has been frozen due to inactivity.^[40]
598 (Informal convention) Network read timeout error: Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.^[41]
599 Network Connect Timeout Error: An error used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Internet Information Services

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

440 Login Time-out: The client’s session has expired and must log in again.^[42]
449 Retry With: The server cannot honour the request because the user has not provided the required information.^[43]
451 Redirect: Used in Exchange ActiveSync when either a more efficient server is available or the server cannot access the users’ mailbox.^[44] The client is expected to re-run the HTTP AutoDiscover operation to find a more appropriate server.^[45]

nginx

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

444 No Response: Used internally^[49] to instruct the server to return no information to the client and close the connection immediately.
494 Request header too large: Client sent too large request or too long header line.
495 SSL Certificate Error: An expansion of the 400 Bad Request response code, used when the client has provided an invalid client certificate.
496 SSL Certificate Required: An expansion of the 400 Bad Request response code, used when a client certificate is required but not provided.
497 HTTP Request Sent to HTTPS Port: An expansion of the 400 Bad Request response code, used when the client has made a HTTP request to a port listening for HTTPS requests.
499 Client Closed Request: Used when the client has closed the request before the server could send a response.

Cloudflare

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

520 Web Server Returned an Unknown Error: The origin server returned an empty, unknown, or unexpected response to Cloudflare.^[51]
521 Web Server Is Down: The origin server refused connections from Cloudflare. Security solutions at the origin may be blocking legitimate connections from certain Cloudflare IP addresses.
522 Connection Timed Out: Cloudflare timed out contacting the origin server.
523 Origin Is Unreachable: Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect or missing.
524 A Timeout Occurred: Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.
525 SSL Handshake Failed: Cloudflare could not negotiate a SSL/TLS handshake with the origin server.
526 Invalid SSL Certificate: Cloudflare could not validate the SSL certificate on the origin web server. Also used by Cloud Foundry’s gorouter.
527 Railgun Error: Error 527 indicates an interrupted connection between Cloudflare and the origin server’s Railgun server.^[52]
530: Error 530 is returned along with a 1xxx error.^[53]

AWS Elastic Load Balancer

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

460: Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer’s timeout.^[54]
463: The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.^[54]
561 Unauthorized: An error around authentication returned by a server registered with a load balancer. You configured a listener rule to authenticate users, but the identity provider (IdP) returned an error code when authenticating the user.^[55]

Caching warning codes (obsoleted)

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.

Explanatory notes

^ Emphasised words and phrases such as must and should represent interpretation guidelines as given by RFC 2119

References

^ ^a ^b ^c «Hypertext Transfer Protocol (HTTP) Status Code Registry». Iana.org. Archived from the original on December 11, 2011. Retrieved January 8, 2015.
^ «RFC 9110: HTTP Semantics and Content, Section 10.1.1 «Expect»«.
^ Goland, Yaronn; Whitehead, Jim; Faizi, Asad; Carter, Steve R.; Jensen, Del (February 1999). HTTP Extensions for Distributed Authoring – WEBDAV. IETF. doi:10.17487/RFC2518. RFC 2518. Retrieved October 24, 2009.
^ Oku, Kazuho (December 2017). An HTTP Status Code for Indicating Hints. IETF. doi:10.17487/RFC8297. RFC 8297. Retrieved December 20, 2017.
^ Stewart, Mark; djna. «Create request with POST, which response codes 200 or 201 and content». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
^ «RFC 9110: HTTP Semantics and Content, Section 15.3.4».
^ «RFC 9110: HTTP Semantics and Content, Section 7.7».
^ ^a ^b ^c ^d ^e Dusseault, Lisa, ed. (June 2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF. doi:10.17487/RFC4918. RFC 4918. Retrieved October 24, 2009.
^ Delta encoding in HTTP. IETF. January 2002. doi:10.17487/RFC3229. RFC 3229. Retrieved February 25, 2011.
^ ^a ^b «RFC 9110: HTTP Semantics and Content, Section 15.4 «Redirection 3xx»«.
^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk (May 1996). Hypertext Transfer Protocol – HTTP/1.0. IETF. doi:10.17487/RFC1945. RFC 1945. Retrieved October 24, 2009.
^ «The GNU Taler tutorial for PHP Web shop developers 0.4.0». docs.taler.net. Archived from the original on November 8, 2017. Retrieved October 29, 2017.
^ «Google API Standard Error Responses». 2016. Archived from the original on May 25, 2017. Retrieved June 21, 2017.
^ «Sipgate API Documentation». Archived from the original on July 10, 2018. Retrieved July 10, 2018.
^ «Shopify Documentation». Archived from the original on July 25, 2018. Retrieved July 25, 2018.
^ «Stripe API Reference – Errors». stripe.com. Retrieved October 28, 2019.
^ «RFC2616 on status 413». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ «RFC2616 on status 414». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ «RFC2616 on status 416». Tools.ietf.org. Archived from the original on March 7, 2011. Retrieved November 11, 2015.
^ TheDeadLike. «HTTP/1.1 Status Codes 400 and 417, cannot choose which». serverFault. Archived from the original on October 10, 2015. Retrieved October 16, 2015.
^ Larry Masinter (April 1, 1998). Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). doi:10.17487/RFC2324. RFC 2324. Any attempt to brew coffee with a teapot should result in the error code «418 I’m a teapot». The resulting entity body MAY be short and stout.
^ I’m a teapot
^ Barry Schwartz (August 26, 2014). «New Google Easter Egg For SEO Geeks: Server Status 418, I’m A Teapot». Search Engine Land. Archived from the original on November 15, 2015. Retrieved November 4, 2015.
^ «Google’s Teapot». Retrieved October 23, 2017.^{[dead link]}
^ «Enable extra web security on a website». DreamHost. Retrieved December 18, 2022.
^ «I Went to a Russian Website and All I Got Was This Lousy Teapot». PCMag. Retrieved December 18, 2022.
^ ^a ^b ^c ^d Nottingham, M.; Fielding, R. (April 2012). «RFC 6585 – Additional HTTP Status Codes». Request for Comments. Internet Engineering Task Force. Archived from the original on May 4, 2012. Retrieved May 1, 2012.
^ Bray, T. (February 2016). «An HTTP Status Code to Report Legal Obstacles». ietf.org. Archived from the original on March 4, 2016. Retrieved March 7, 2015.
^ alex. «What is the correct HTTP status code to send when a site is down for maintenance?». Stack Overflow. Archived from the original on October 11, 2016. Retrieved October 16, 2015.
^ Holtman, Koen; Mutz, Andrew H. (March 1998). Transparent Content Negotiation in HTTP. IETF. doi:10.17487/RFC2295. RFC 2295. Retrieved October 24, 2009.
^ Nielsen, Henrik Frystyk; Leach, Paul; Lawrence, Scott (February 2000). An HTTP Extension Framework. IETF. doi:10.17487/RFC2774. RFC 2774. Retrieved October 24, 2009.
^ «Enum HttpStatus». Spring Framework. org.springframework.http. Archived from the original on October 25, 2015. Retrieved October 16, 2015.
^ «Twitter Error Codes & Responses». Twitter. 2014. Archived from the original on September 27, 2017. Retrieved January 20, 2014.
^ «HTTP Status Codes and SEO: what you need to know». ContentKing. Retrieved August 9, 2019.
^ «Screenshot of error page». Archived from the original (bmp) on May 11, 2013. Retrieved October 11, 2009.
^ ^a ^b «Using token-based authentication». ArcGIS Server SOAP SDK. Archived from the original on September 26, 2014. Retrieved September 8, 2014.
^ «HTTP Error Codes and Quick Fixes». Docs.cpanel.net. Archived from the original on November 23, 2015. Retrieved October 15, 2015.
^ «SSL Labs API v3 Documentation». github.com.
^ «Platform Considerations | Pantheon Docs». pantheon.io. Archived from the original on January 6, 2017. Retrieved January 5, 2017.
^ «HTTP status codes — ascii-code.com». www.ascii-code.com. Archived from the original on January 7, 2017. Retrieved December 23, 2016.
^
«Error message when you try to log on to Exchange 2007 by using Outlook Web Access: «440 Login Time-out»«. Microsoft. 2010. Retrieved November 13, 2013.
^ «2.2.6 449 Retry With Status Code». Microsoft. 2009. Archived from the original on October 5, 2009. Retrieved October 26, 2009.
^ «MS-ASCMD, Section 3.1.5.2.2». Msdn.microsoft.com. Archived from the original on March 26, 2015. Retrieved January 8, 2015.
^ «Ms-oxdisco». Msdn.microsoft.com. Archived from the original on July 31, 2014. Retrieved January 8, 2015.
^ «The HTTP status codes in IIS 7.0». Microsoft. July 14, 2009. Archived from the original on April 9, 2009. Retrieved April 1, 2009.
^ «ngx_http_request.h». nginx 1.9.5 source code. nginx inc. Archived from the original on September 19, 2017. Retrieved January 9, 2016.
^ «ngx_http_special_response.c». nginx 1.9.5 source code. nginx inc. Archived from the original on May 8, 2018. Retrieved January 9, 2016.
^ «return» directive Archived March 1, 2018, at the Wayback Machine (http_rewrite module) documentation.
^ «Troubleshooting: Error Pages». Cloudflare. Archived from the original on March 4, 2016. Retrieved January 9, 2016.
^ «Error 520: web server returns an unknown error». Cloudflare. Retrieved November 1, 2019.
^ «527 Error: Railgun Listener to origin error». Cloudflare. Archived from the original on October 13, 2016. Retrieved October 12, 2016.
^ «Error 530». Cloudflare. Retrieved November 1, 2019.
^ ^a ^b «Troubleshoot Your Application Load Balancers – Elastic Load Balancing». docs.aws.amazon.com. Retrieved August 27, 2019.
^ «Troubleshoot your Application Load Balancers — Elastic Load Balancing». docs.aws.amazon.com. Retrieved January 24, 2021.
^ «Hypertext Transfer Protocol (HTTP/1.1): Caching». datatracker.ietf.org. Retrieved September 25, 2021.
^ «Warning — HTTP | MDN». developer.mozilla.org. Retrieved August 15, 2021. Some text was copied from this source, which is available under a Creative Commons Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5) license.
^ «RFC 9111: HTTP Caching, Section 5.5 «Warning»«. June 2022.

External links

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

Источник

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. Данная публикация будет о HTTP кодах состояния перенаправления. К HTTP кодам перенаправления относятся следующие коды: 300, 301, 302, 303, 304, 305, 306, 307. Напомню, что коды перенаправления говорят клиенту о том, что для успешного завершения запроса необходимо выполнить какое-то действие. Обычно браузеры выполняют такие действия без вмешательства пользователя. В данной записи мы рассмотрим сперва все HTTP коды перенаправления, а затем рассмотрим каждый код в отдельности более подробно.

HTTP коды состояния перенаправления: 300, 301, 302, 303, 304, 305, 306, 307

Общая информации о HTTP кодах перенаправления

Содержание статьи:

Общая информации о HTTP кодах перенаправления
HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.
HTTP код состояния 303: смотреть другой ресурс. HTTP код состояния 304: ресурс не модифицирован. HTTP код состояния 305: использовать прокси сервер. HTTP код состояния 307: временное перенаправление

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Да, эти коды состояния, как раз и есть тот самый Redirect 301 или склейка доменов, глупое выражение: Redirect 301 – склейка домена. Автор тоже этим грешил, автор каится и обещает исправиться. Все дело в том, что 301 – это всего лишь, код, который означает, что произошло перенаправление, а вот за склейку доменов отвечает HTTP сервер и его конфигурации, поэтому крайне неправильно говорить этот ваш редирект 301.

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

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

HTTP ответ	Описание кода состояния перенаправления
300 Multiple Choices	HTTP код перенаправления 300: множественный выбор HTTP код состояния 300 говорит клиенту о том, что запрошенный ресурс имеет несколько представлений и клиент в праве выбрать одно из предлагаемых представлений. Действует ограничение в пять адресов максимум.
301 Moved Permanently	HTTP код перенаправления 301: постоянно перемещен HTTP код состояния 301 говорит клиенту о том, что запрашиваемая страница была перенесена на новый адрес, обычно браузер автоматически переходит по новому адресу.
302 Found	HTTP код перенаправления 302: временно перемещен HTTP код состояния 302 говорит клиенту о том, что запрашиваемый ресурс был временно перемещен на новый адрес.
303 See Other	HTTP код перенаправления 303: смотри другой HTTP код состояния 303 говорит клиенту о том, что ответ на запрос может быть найден по другому URI (про URI в HTTP найдешь информацию здесь), новый запрос следует выполнять методом GET (про HTTP методы смотри здесь).
304 Not Modified	HTTP код перенаправления 304: не модифицирован HTTP код состояния 304 говорит клиенту о том, что сервер выполнил условный GET запрос, но документ никак не изменился.
305 Use Proxy	HTTP код перенаправления 305: используй прокси HTTP код состояния 304 говорит клиенту о том, что запрошенный URL должен быть доступен через прокси, который указан в поле заголовка Location.
306 Unused	HTTP код перенаправления 306: зарезервировано Код состояния 306 использовался в прошлой версии HTTP протокола, на данный момент он не используется, но зарезервирован стандартом HTTP.
307 Temporary Redirect	HTTP код перенаправления 307: временно перемещен HTTP код состояния 307 говорит клиенту о том, что запрашиваемая страница временно переехала на новый адрес

Давайте более подробно поговорим про каждый из кодов состояний HTTP сервера класса перенаправления.

HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.

HTTP код состояния 300 или код множественного выбора говорит о том, что клиент может выбрать несколько доступных представлений ресурса, но не более пяти. Каждое представление ресурса имеет свое уникальное месторасположения на сервере. Формат, в котором клиент будет получать HTTP объект определяется медиа типом данных (читай про типы данных в HTTP по этой ссылке), указанным в поле заголовка Content-Type. Иногда выбор выполняется автоматически браузером без участия пользователя, но стандарт HTTP протокола не дает никаких критериев, по которым должен происходить автоматический выбор, а так же не имеет никаких требований. Ответы HTTP сервера с кодом состояния 300 по умолчанию являются кэшируемыми, если в заголовках не указано иного.

HTTP код состояния 301 или код состояния постоянного переноса. Код состояния 301 сообщает браузеру о том, что для ресурса, к которому он обратился, назначен новый URI, и все обращения к этому ресурсу следует выполнять по новому URI, указанному в ответе HTTP сервера. Ответы сервера с кодом 301 являются кэшируемыми. В тех случаях, когда клиент использовал HTTP запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.

HTTP код состояния 302 или код временного перемещения ресурса. Код состояния 302 говорит о том, что на данный момент ресурс временно доступен по другому URI и сообщает новый URI ресурса. Кэшируемость ответов сервера с кодом 302 зависит только от значений полей заголовка Cache-Control или Expires. В тех случаях, когда клиент использовал запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.

HTTP код состояния 303: смотреть другой ресурс. HTTP код состояния 304: ресурс не модифицирован. HTTP код состояния 305: использовать прокси сервер. HTTP код состояния 307: временное перенаправление

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

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

Date;
ETag или Content-Location;
Expires, Cache-Control или

Ответы сервера с кодом 304 всегда завершаются пустой строкой после полей заголовка.

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

HTTP код состояния 306 использовался в старых версиях протокола HTTP, но теперь является просто зарезервированным.

HTTP код состояния 307 аналогичен коду состояния 302.

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

Источник

part of Hypertext Transfer Protocol — HTTP/1.1
RFC 2616 Fielding, et al.

Each Status-Code is described below, including a description of which
method(s) it can follow and any metainformation required in the
response.

10.1 Informational 1xx

This class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is
terminated by an empty line. There are no required headers for this
class of status code. Since HTTP/1.0 did not define any 1xx status
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
except under experimental conditions.

A client MUST be prepared to accept one or more 1xx status responses
prior to a regular response, even if the client does not expect a 100
(Continue) status message. Unexpected 1xx status responses MAY be
ignored by a user agent.

Proxies MUST forward 1xx responses, unless the connection between the
proxy and its client has been closed, or unless the proxy itself
requested the generation of the 1xx response. (For example, if a

proxy adds a «Expect: 100-continue» field when it forwards a request,
then it need not forward the corresponding 100 (Continue)
response(s).)

10.1.1 100 Continue

The client SHOULD continue with its request. This interim response is
used to inform 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. See
section 8.2.3 for detailed discussion of the use and handling of this
status code.

10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client’s
request, via the Upgrade message header field (section 14.42), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response’s
Upgrade header field immediately after the empty line which
terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do
so. For example, switching to a newer version of HTTP is advantageous
over older versions, and switching to a real-time, synchronous
protocol might be advantageous when delivering resources that use
such features.

10.2 Successful 2xx

This class of status code indicates that the client’s request was
successfully received, understood, and accepted.

10.2.1 200 OK

The request has succeeded. 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.

10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being
created. 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 response
SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The entity format is specified by
the media type given in the Content-Type 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 202 (Accepted) response instead.

A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag for the requested variant just
created, see section 14.19.

10.2.3 202 Accepted

The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be
acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an
asynchronous operation such as this.

The 202 response is intentionally non-committal. 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 or some estimate of when the
user can expect the request to be fulfilled.

10.2.4 203 Non-Authoritative Information

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. For example, including local
annotation information about the resource might result in a superset
of the metainformation known by the origin server. Use of this
response code is not required and is only appropriate when the
response would otherwise be 200 (OK).

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

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, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent’s active view.

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

10.2.6 205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset
the document view which caused the request to be sent. This response
is primarily intended to allow input for actions to take place via
user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The
response MUST NOT include an entity.

10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (section 14.35)
indicating the desired range, and MAY have included an If-Range
header field (section 14.27) to make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the
        message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the 206 response is the result of an If-Range request that used a
strong cache validator (see section 13.3.3), the response SHOULD NOT
include other entity-headers. If the response is the result of an
If-Range request that used a weak validator, the response MUST NOT
include other entity-headers; this prevents inconsistencies between
cached entity-bodies and updated headers. Otherwise, the response
MUST include all of the entity-headers that would have been returned
with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly,
see 13.5.4.

A cache that does not support the Range and Content-Range headers
MUST NOT cache 206 (Partial) responses.

10.3 Redirection 3xx

This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request is
GET or HEAD. A client SHOULD detect infinite redirection loops, since
such loops generate network traffic for each redirection.

      Note: previous versions of this specification recommended a
      maximum of five redirections. Content developers should be aware
      that there might be clients that implement such a fixed
      limitation.

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent-
driven negotiation information (section 12) is being provided so that
the user (or user agent) can select a preferred representation and
redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be
performed automatically. However, this specification does not define
any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD
include the specific URI for that representation in the Location
field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.

The new permanent 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 301 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.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

10.3.3 302 Found

The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.

If the 302 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.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. 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.

10.3.4 303 See Other

The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.

The different 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).

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line
after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and
clients add their own Date to any response received without one (as
already specified by [RFC 2068], section 14.19), caches will operate
correctly.

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
conditional.

If a cache uses a received 304 response to update a cache entry, the
cache MUST update the entry to reflect any new field values given in
the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URI of the proxy.
The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers.

      Note: RFC 2068 was not clear that 305 was intended to redirect a
      single request, and to be generated by origin servers only.  Not
      observing these limitations has significant security consequences.

10.3.7 306 (Unused)

The 306 status code was used in a previous version of the
specification, is no longer used, and the code is reserved.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI.
Since the redirection MAY be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.

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) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the
information necessary for a user to repeat the original request on
the new URI.

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.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the
client seems to have erred. 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.

If the client is sending data, a server implementation using TCP
SHOULD be careful to ensure that the client acknowledges receipt of
the packet(s) containing the response, before the server closes the
input connection. If the client continues sending data to the server
after the close, the server’s TCP stack will send a reset packet to
the client, which may erase the client’s unacknowledged input buffers
before they can be read and interpreted by the HTTP application.

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8). 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. HTTP access authentication
is explained in «HTTP Authentication: Basic and Digest Access
Authentication» [43].

10.4.3 402 Payment Required

This code is reserved for future use.

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. 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.

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most
appropriate. The entity format is specified by the media type given
in the Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate
choice MAY be performed automatically. However, this specification
does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

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.

10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the
client must first authenticate itself with the proxy. The proxy MUST
return a Proxy-Authenticate header field (section 14.33) containing a
challenge applicable to the proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization
header field (section 14.34). HTTP access authentication is explained
in «HTTP Authentication: Basic and Digest Access Authentication»
[43].

10.4.9 408 Request Timeout

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.

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict
and resubmit the request. The response body SHOULD include enough

information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the entity being PUT
included changes to a resource which conflict with those made by an
earlier (third-party) request, the server might use the 409 response
to indicate that it can’t complete the request. In this case, the
response entity would likely contain a list of the differences
between the two versions in a format defined by the response
Content-Type.

10.4.11 410 Gone

The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be
considered permanent. Clients with link editing capabilities SHOULD
delete references to the Request-URI after user approval. If the
server does not know, or has no facility to determine, whether or not
the condition is permanent, the status code 404 (Not Found) SHOULD be
used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server’s site. It is not
necessary to mark all permanently unavailable resources as «gone» or
to keep the mark for any length of time — that is left to the
discretion of the server owner.

10.4.12 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 containing the length of the message-body
in the request message.

10.4.13 412 Precondition Failed

The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This response
code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended.

10.4.14 413 Request Entity Too Large

The server is refusing to process a request because the request
entity is larger than the server is willing or able to process. The
server MAY close the connection to prevent the client from continuing
the request.

If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what
time the client MAY try again.

10.4.15 414 Request-URI Too Long

The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query
information, when the client has descended into a URI «black hole» of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.

10.4.16 415 Unsupported Media Type

The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource
for the requested method.

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request
included a Range request-header field (section 14.35), and none of
the range-specifier values in this field overlap the current extent
of the selected resource, and the request did not include an If-Range
request-header field. (For byte-ranges, this means that the first-
byte-pos of all of the byte-range-spec values were greater than the
current length of the selected resource.)

When this status code is returned for a byte-range request, the
response SHOULD include a Content-Range entity-header field
specifying the current length of the selected resource (see section
14.16). This response MUST NOT use the multipart/byteranges content-
type.

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section
14.20) could not be met by this server, or, if the server is a proxy,
the server has unambiguous evidence that the request could not be met
by the next-hop server.

10.5 Server Error 5xx

Response status codes beginning with the digit «5» indicate cases in
which the server is aware that it has erred or is 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 whether it is a temporary or permanent
condition. User agents SHOULD display any included entity to the
user. These response codes are applicable to any request method.

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it
from fulfilling the request.

10.5.2 501 Not Implemented

The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not
recognize the request method and is not capable of supporting it for
any resource.

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to
fulfill the request.

10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay MAY be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a
timely response from the upstream server specified by the URI (e.g.
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
to access in attempting to complete the request.

      Note: Note to implementors: some deployed proxies are known to
      return 400 or 500 when DNS lookups time out.

10.5.6 505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in section
3.1, other than with this error message. The response SHOULD contain
an entity describing why that version is not supported and what other
protocols are supported by that server.

Источник

В этой статье представлен номер ошибки Ошибка 303, широко известный как См. Другое, описанный как «Это сообщение об ошибке» «см. Другой» «SRC. Данные находятся где-то в другом месте, и для их получения используется метод GET».

О кодах состояния

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

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

Определения (Бета)

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

Сообщение — сообщения Facebook, сообщения JavaScript, мобильные сообщения Android, iOS, windows-phone и т. д.
Src — SRC — это общий атрибут в HTML, используемый для определения местоположения ресурса, который относится к элементу.
Метод . Метод, часто называемый функцией, подпрограммой или процедурой, — это код, который выполняет задача и связана с классом или объектом.

Симптомы Ошибка 303 — См. Другое

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

3xx: Перенаправление
Этот код состояния отправляется обратно клиенту, если пользователю необходимо предпринять дополнительные действия для завершения запроса. Пользователь либо получает уведомление о том, что содержимое временно или постоянно недоступно, либо получает кликабельный URI на сайт, куда перемещено запрашиваемое содержимое. Действия, которые необходимо предпринять пользователю, выделены жирным шрифтом, например, следующим образом:

300 — Множественные варианты

301 — Перемещено навсегда

302 — Найдено

303 — Посмотреть другие

304 — Не изменено

305 — Использовать прокси

307 — Временное перенаправление

(Только для примера)

Причины См. Другое — Ошибка 303

Коды 3XX возникают из-за определенных изменений, внесенных в исходный URI, и необходимости перенаправить пользователя на другой URI или некоторых других действий, описанных на странице ошибки.

Методы устранения

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

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

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

Метод 3 — Проверить запрошенный URL

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

Метод 1 — Очистить кеш браузера

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

В Google Chrome

Откройте Chrome и нажмите три точки в правом верхнем углу браузера.
Нажмите Дополнительные инструменты , а затем нажмите Очистить данные просмотра .
Вы можете удалить все или только определенный период просмотра.
Установите флажки рядом с файлами cookie и другими данными сайта и кэшированными изображениями и файлами .
Наконец, нажмите Очистить данные .

На краю

Нажмите … это крайняя правая кнопка под кнопкой закрытия.
Прокрутите вниз и нажмите «Настройки».
Найдите пункт «Очистить данные просмотра» и нажмите кнопку «Выбрать, что очистить».
Это даст вам возможность выбрать, какой тип данных вы хотите очистить, просто поставьте галочку на тех элементах, которые хотите включить, затем нажмите «Очистить».

В Mozilla

Перейдите в меню «История» и выберите «Очистить недавнюю историю».
Вы можете нажать кнопку Alt, если строка меню скрыта.
Вы увидите раскрывающееся меню, в котором вы можете выбрать период или диапазон, который хотите удалить, и щелкните свой выбор.
Вы можете нажать «Подробности», чтобы выбрать, что нужно очистить, будь то весь кеш или другие элементы.
После выбора нажмите «Очистить сейчас» и перезагрузите браузер, чтобы изменения вступили в силу.

Метод 2 — Проверить журналы

Если вы хотите проверить файлы журналов, вы можете сделать это, сначала убедившись, что вы вошли на компьютер веб-сервера как администратор.
Нажмите «Пуск», затем «Настройка», затем нажмите «Панель управления».
Откройте Инструменты администратора и дважды щелкните Диспетчер служб Интернета.
Выберите веб-сайт из списка различных обслуживаемых сайтов.
Щелкните веб-сайт правой кнопкой мыши и затем наведите указатель мыши на «Свойства».
Выберите вкладку «Веб-сайт» и нажмите «Свойства». На нем вы увидите вкладку Общие свойства. Внизу окна вы можете увидеть расположение сгенерированных файлов журнала.
Открывайте файлы журналов с помощью WordPad, любого средства просмотра текстовых файлов или Microsoft Word.
Здесь вы сможете проанализировать, где возникли ошибки при доступе к серверу.

Метод 4 — Удалить последние обновления

Для Windows 7

Найдите обновления Windows в строке поиска.
Нажмите «Ввод», когда он появится в результатах поиска.
Проверьте последние обновления и нажмите Удалить обновления в те дни, когда возникла ошибка.

Для Windows 8 и Windows 10

Нажмите одновременно кнопку окна и букву X, чтобы открыть настройки.
Когда вы перейдете к настройкам Windows, нажмите «Обновление и безопасность».
Нажмите «Просмотреть историю установленных обновлений», а затем «Удалить обновления».

Метод 5 — Удалить расширения

Иногда дополнительные расширения могут выдавать коды веб-ошибок.
Удалите недавно установленные расширения, зайдя в настройки браузера и нажав «Дополнительные инструменты».
Вы увидите расширения, которые не были установлены в вашем браузере, выберите последнее дополнение, которое, как вы подозреваете, вызвало возникшую у вас проблему.

Метод 6 — Проверить конфигурацию сервера

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

Метод 7 — Другие техники

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

Другие языки:

How to fix Error 303 (See Other) — «This error message is a «»see other»» SRC. The data is somewhere else and the GET method is used to retrieve it.»
Wie beheben Fehler 303 (Siehe Andere) — «Diese Fehlermeldung ist ein «»see other»» SRC. Die Daten sind woanders und die GET-Methode wird verwendet, um sie abzurufen.»
Come fissare Errore 303 (Vedi Altro) — «Questo messaggio di errore è un SRC «»vedi altro»». I dati sono da qualche altra parte e viene utilizzato il metodo GET per recuperarli.»
Hoe maak je Fout 303 (ZieÂAndere) — «Deze foutmelding is een «»zie andere»» SRC. De gegevens staan ergens anders en de GET-methode wordt gebruikt om ze op te halen.»
Comment réparer Erreur 303 (Voir Autre) — «Ce message d’erreur est un SRC «»voir autre»». Les données sont ailleurs et la méthode GET est utilisée pour les récupérer.»
어떻게 고치는 지 오류 303 (기타 참조) — «이 오류 메시지는 «»기타 보기»» SRC입니다. 데이터는 다른 곳에 있으며 GET 메서드를 사용하여 검색합니다.»
Como corrigir o Erro 303 (Ver outro) — «Esta mensagem de erro é um» «veja outro» «SRC. Os dados estão em outro lugar e o método GET é usado para recuperá-los.»
Hur man åtgärdar Fel 303 (Se Övrigt) — «Detta felmeddelande är en» «se annan» «SRC. Data finns någon annanstans och GET -metoden används för att hämta den.»
Jak naprawić Błąd 303 (Zobacz Inne) — „Ten komunikat o błędzie to kod SRC „zobacz inne”. Dane znajdują się gdzie indziej i do ich pobrania użyto metody GET”.
Cómo arreglar Error 303 (Ver otro) — «Este mensaje de error es un» «ver otro» «SRC. Los datos están en otro lugar y se utiliza el método GET para recuperarlos».

Об авторе: Фил Харт является участником сообщества Microsoft с 2010 года. С текущим количеством баллов более 100 000 он внес более 3000 ответов на форумах Microsoft Support и создал почти 200 новых справочных статей в Technet Wiki.

Следуйте за нами:

Последнее обновление:

04/04/22 07:17 : Пользователь Android проголосовал за то, что метод восстановления 6 работает для него.

Рекомендуемый инструмент для ремонта:

Этот инструмент восстановления может устранить такие распространенные проблемы компьютера, как синие экраны, сбои и замораживание, отсутствующие DLL-файлы, а также устранить повреждения от вредоносных программ/вирусов и многое другое путем замены поврежденных и отсутствующих системных файлов.

ШАГ 1:

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

ШАГ 2:

Нажмите на Start Scan и позвольте ему проанализировать ваше устройство.

ШАГ 3:

Нажмите на Repair All, чтобы устранить все обнаруженные проблемы.

СКАЧАТЬ СЕЙЧАС

Совместимость

Требования

1 Ghz CPU, 512 MB RAM, 40 GB HDD
Эта загрузка предлагает неограниченное бесплатное сканирование ПК с Windows. Полное восстановление системы начинается от $19,95.

ID статьи: ACX01636RU

Применяется к: Windows 10, Windows 8.1, Windows 7, Windows Vista, Windows XP, Windows 2000

Совет по увеличению скорости #42

Работайте быстрее с блокировщиком рекламы:

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

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

Источник

Example[edit]

See also[edit]

References[edit]

1xx informational response

2xx success

3xx redirection

4xx client errors

5xx server errors

Unofficial codes

Internet Information Services

nginx

Cloudflare

AWS Elastic Load Balancer

Caching warning codes (obsoleted)

See also

Explanatory notes

References

External links

1xx informational response

2xx success

3xx redirection

4xx client errors

5xx server errors

Unofficial codes

Internet Information Services

nginx

Cloudflare

AWS Elastic Load Balancer

Caching warning codes (obsoleted)

See also

Explanatory notes

References

External links

Общая информации о HTTP кодах перенаправления

HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.

10.1 Informational 1xx

10.1.1 100 Continue

10.1.2 101 Switching Protocols

10.2 Successful 2xx

10.2.1 200 OK

10.2.2 201 Created

10.2.3 202 Accepted

10.2.4 203 Non-Authoritative Information

10.2.5 204 No Content

10.2.6 205 Reset Content

10.2.7 206 Partial Content

10.3 Redirection 3xx

10.3.1 300 Multiple Choices

10.3.2 301 Moved Permanently

10.3.3 302 Found

10.3.4 303 See Other

10.3.5 304 Not Modified

10.3.6 305 Use Proxy

10.3.7 306 (Unused)

10.3.8 307 Temporary Redirect

10.4 Client Error 4xx

10.4.1 400 Bad Request

10.4.2 401 Unauthorized

10.4.3 402 Payment Required

10.4.4 403 Forbidden

10.4.5 404 Not Found

10.4.6 405 Method Not Allowed

10.4.7 406 Not Acceptable

10.4.8 407 Proxy Authentication Required

10.4.9 408 Request Timeout

10.4.10 409 Conflict

10.4.11 410 Gone

10.4.12 411 Length Required

10.4.13 412 Precondition Failed

10.4.14 413 Request Entity Too Large

10.4.15 414 Request-URI Too Long

10.4.16 415 Unsupported Media Type

10.4.17 416 Requested Range Not Satisfiable

10.4.18 417 Expectation Failed

10.5 Server Error 5xx

10.5.1 500 Internal Server Error

10.5.2 501 Not Implemented

10.5.3 502 Bad Gateway

10.5.4 503 Service Unavailable

10.5.5 504 Gateway Timeout