This is the fourth day of my participation in the August More text Challenge. For details, see: August More Text Challenge

Recently, I have been doing a series of summary questions on the front end, interested friends can add attention, welcome correction, communication.

Strive for each knowledge point to be able to sum up some more, at least to do in the interview, for each knowledge point can be kan, not dumb fire.

preface

From the previous summary, we know that when a client sends a request to a server over HTTP, it always expects the server to respond. In the response from the server, the header contains a property called Status Code, which is a three-digit number. This number is referred to as the HTTP Status Code.

HTTP status code is an important part of THE HTTP protocol. It is used to indicate the response status of the server to the current request.

concept

An HTTP Status Code is a three-digit Code used to indicate the Status of HTTP protocol responses from a Web server.

It is defined by RFC 2616 and extended by RFC 2518, RFC 2817, RFC 2295, RFC 2774 and RFC 4918.

The first digit of all status codes represents one of the five states of the response. The message phrase shown is typical, but can provide any readable alternative.

classification

HTTP status codes are divided into five categories, as shown in the figure below:

1 xx news

This type of status code indicates that the request has been accepted and needs to continue processing. It has the following features:

  • This type of response is a temporary response that contains only the status line and some optional response header information and ends with a blank line.
  • Since there are no 1XX status codes defined in THE HTTP/1.0 protocol, the server is prohibited from sending 1XX responses to such clients except under certain experimental conditions.
  • The responses represented by these status codes are informational, indicating that the client should wait for the server to take further action.

100 Continue

The server has received the request header, and the client should continue sending the request body (in the case of a request that needs to send a body: for example, a POST request), or ignore the response if the request has completed.

The server must send a final response to the client after the request is completed.

For the server to check the header of the request, the client must send Expect: 100-continue as the header in its initial request and receive the 100 continue status code before sending the body.

101 Switching Protocols

The server has understood the client’s request and will use the Upgrade header to inform the client to use a different protocol to complete the request. After sending the blank line at the end of the response, the server will switch to the protocols defined in the Upgrade header.

Such measures should be taken only when switching to a new protocol is more beneficial. For example, switching to a new HTTP version (such as HTTP/2) has advantages over older versions, or switching to a real-time, synchronous protocol (such as WebSocket) to deliver resources that take advantage of such features.

102 Processing

A WebDAV request can contain many sub-requests involving file operations that take a long time to complete. This code indicates that the server has received and is processing the request, but no response is available. This prevents the client from timeout and assumes that the request is lost.

103 Early Hints

Used to return some response headers before the final HTTP message.

2 xx success

This type of status code indicates that the request has been successfully received, understood, and accepted by the server.

200 OK

The request was successful, and the desired response header or body is returned with this response. If this status code is displayed, it indicates the normal state.

201 Created

The request has been implemented, and a new resource has been created as required by the request, and its URI has been returned with the Location header.

If the required resource cannot be built in time, return ‘202 Accepted’.

202 Accepted

The server has accepted the request but has not yet processed it. Just as it may be rejected, ultimately the request may or may not be executed. In the case of asynchronous operations, nothing is more convenient than sending this status code.

The purpose of a response that returns a status code 202 is to allow the server to accept requests for other procedures (such as a batch-based operation that is performed only once a day) without having to keep the client connected to the server until the batch operation is complete.

A response that accepts request processing and returns a 202 status code should include in the returned entity some information indicating the current state of processing, as well as a pointer to a processing status monitor or state prediction, so that the user can estimate whether the operation has completed.

203 Non-Authoritative Information

The server successfully processed the request, but the entity header meta information returned is not a definitive collection valid on the original server, but a copy from a local or third party. The current information may be a subset or superset of the original version. For example, metadata containing resources may cause the original server to know a superset of metadata. Use of this status code is not required and is only appropriate if the response returns 200 OK without using this status code.

204 No Content

The server successfully processed the request, but does not need to return any entity content and wants to return updated meta information. The response may return new or updated meta information in the form of an entity header. If this header information exists, it should correspond to the requested variable.

If the client is a browser, the user’s browser should retain the page where the request was sent without any changes to the document view, even though new or updated meta information should be applied to the document in the user’s browser activity view according to the specification.

Because the 204 response is forbidden to contain any message body, it always ends with the first blank line after the message header.

205 Reset Content

The server successfully processed the request and returned nothing.

But unlike a 204 response, a response that returns this status code requires the requester to reset the document view. This response is primarily used to reset the form immediately after accepting user input so that the user can easily start another input.

Like the 204 response, this response is forbidden to contain any message body and ends with the first blank line after the message header.

206 Partial Content

The server has successfully processed some of the GET requests. HTTP download tools such as FlashGet or Thunderbolt use this type of response to enable breakpoint or to split a large document into multiple download segments for simultaneous download.

The request must contain Range header information to indicate the Range of content the client expects, and may include if-range as a request condition.

The response must contain the following header field:

  • Content-range indicates the Range of Content returned in this response. If the download is multipart/ Byteranges, each multipart section should contain a content-range field to indicate the Content Range of the section. If the response contains content-length, then its value must match the true number of bytes of the Content range it returns.

  • Date

  • ETag and/or content-location, if the same request should have returned a 200 response.

  • Expires, cache-control, and/or Vary, if the value is likely to be different from other responses to the same variable previously.

If this response request uses if-range strong cache validation, then this response should not contain other entity headers; If the request for this response uses if-range weak cache validation, then this response is not allowed to contain other entity headers. This avoids any inconsistency between the cached entity content and the updated entity header. Otherwise, this response should contain all the entity header fields that should have been returned in the response that should have returned 200.

If the ETag or last-Modified header does not match exactly, then the client cache should disallow combining the content returned by the 206 response with any previously cached content.

207 Multi-Status

The status code, extended by WebDAV(RFC 2518), means that the body of the subsequent message will be an XML message and may contain a series of separate response codes depending on the number of previous sub-requests.

208 Already Reported

Members of the DAV binding have been listed in the previous part of the (multi-state) response and have not been included again.

226 IM Used

The resulting representation of one or more entity operations requested by an entity that the server has fulfilled a request for a resource.

3 xx redirection

This type of status code indicates that the client needs to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirection targets) are specified in the Location field of this response.

The user’s browser can automatically submit the required subsequent requests without user intervention if and only if the subsequent request uses the GET or HEAD method.

The client should automatically monitor for infinite loop redirection (for example: A->A, or A->B->C->A), as this can cause A large amount of unnecessary resource consumption on both the server and client.

As recommended by the HTTP/1.0 specification, browsers should not automatically access redirects more than 5 times.

300 Multiple Choices

The requested resource has an alternative set of responses, each with its own specific address and browser-driven negotiation. The user or browser can choose a preferred address to redirect to.

Unless this is a HEAD request, the response should include an entity with a list of resource features and addresses, from which the user or browser can choose the most appropriate redirect address. The format of this entity is determined by the format defined by the content-type. The browser may automatically make the most appropriate choice based on the format of the response and the browser’s own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should proceed.

If the server itself already has a preferred feedback option, specify the URI of the feedback in the Location; The browser may use this Location value as the address for automatic redirection. In addition, this response is cacheable unless otherwise specified.

304 Not Modified

Indicates that the resource has not been Modified Since the version specified by the if-modified-since or if-none-match arguments in the request header. In this case, there is no need to retransfer resources because the client still has a copy of the previous download.

306 Switch Proxy

In the latest version of the specification, the 306 status code is no longer used. Originally it meant “subsequent requests should use the specified proxy.”

4XX Client error

This type of status code represents a situation where the client appears to have made an error that hampers the server’s processing. Unless you are responding to a HEAD request, the server should return an entity that explains the current error condition and whether it is temporary or permanent. These status codes apply to any request method. The browser should show the user the content of any entity contained in such an error response.

If the client is transmitting data when the error occurs, server implementations using TCP should be careful to ensure that the client has received a packet containing the error message before closing the connection between the client and the server. If the client continues to send data to the server after receiving the error message, the server’s TCP stack will send a reset packet to the client to clear any input buffer that the client has not yet identified, lest the data be read and interfered with by the application on the server.

400 Bad Request

There are two possibilities:

  • The current request cannot be understood by the server. The client should not repeat the request unless it is modified.
  • The request parameter is incorrect.

401 Unauthorized

The current request requires user authentication. The response must contain a wwW-Authenticate header applicable to the requested resource to ask for user information. The client can repeatedly submit a request with the appropriate Authorization header. If the current request already contains Authorization certificates, the 401 response represents that the server authentication has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has already tried to authenticate at least once, the browser should show the user the entity information contained in the response, as this entity information may contain relevant diagnostic information.

403 Forbidden

The server understood the request, but refused to perform it. Unlike the 401 response, authentication does not help, and the request should not be submitted twice. If it is not a HEAD request and the server wants to be able to explain why the request cannot be executed, the reason for the rejection should be described in the entity. Of course, the server can return a 404 response if it doesn’t want the client to get any information.

404 Not Found

The requested resource was not found on the server. There is no information to tell the user whether the condition is temporary or permanent. If the server knows this, it should use the 410 status code to inform the server that the old resource is permanently unavailable due to some internal configuration mechanism problem and that there is no address to jump to. The 404 status code is widely used when the server does not want to reveal exactly why the request was rejected or no other suitable response is available. The most likely reason for this error is that the page does not exist on the server side.

405 Method Not Allowed

The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header that represents a list of request methods that the current resource can accept.

Since the PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow these methods by default, and will return a 405 error on such requests.

406 Not Acceptable

The content characteristics of the requested resource do not satisfy the conditions in the request header, so the response entity cannot be generated.

Unless this is a HEAD request, the response should return an entity containing the most appropriate entity features and address list for the user or browser to select. The format of the entity is determined by the media Type defined in the Content-Type header. The browser can make the best choice based on the format and its own capabilities. However, the specification does not define any criteria for making such automatic choices.

408 Request Timeout

The request timed out. The client did not complete sending a request during the time the server was ready to wait. The client can resubmit the request at any time without any changes.

5xx The server is incorrect

This kind of status code represents that the server has an error or abnormal status in the process of processing the request, or the server may realize that the current hardware and software resources cannot complete the processing of the request. Unless this is a HEAD request, the server should contain an entity that explains the current error status and whether the condition is temporary or permanent. The browser should show the user any entities that are included in the current response.

These status codes apply to any response method.

500 Internal Server Error

The server encountered an unexpected situation that caused it to be unable to complete processing the request. In general, this problem occurs when the source code on the server side is faulty.

501 Not Implemented

The server does not support a feature required by the current request. When the server cannot recognize the method of the request and cannot support its request for any resource.

502 Bad Gateway

When a server working as a gateway or proxy tries to execute the request, it receives an invalid response from the upstream server.

503 Service Unavailable

The server is currently unable to process requests due to temporary server maintenance or overload. The condition is temporary and will recover over time. If the delay time can be predicted, the response can include a retry-After header to indicate the delay time. If this Retry-after information is not given, the client should process it as if it were a 500 response.

Note: The presence of a 503 status code does not mean that the server must use it when overloaded. Some servers simply want to deny clients access.

504 Gateway Timeout

When a server working as a gateway or proxy tries to execute the request, it does not receive a response in time from either the upstream server (identified by THE URI, such as HTTP, FTP, LDAP) or the secondary server (such as DNS).

Note: Some proxy servers may return a 400 or 500 error when the DNS query times out

505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or will not use the same version as the client. The response should include an entity that describes why the version is not supported and what protocols the server supports.

507 Insufficient Storage

The server was unable to store the content necessary to complete the request. The situation is considered temporary.

511 Network Authentication Required

Clients need to authenticate to gain network access, which is designed to restrict user groups from accessing a specific network.

conclusion

Through the HTTP status code, we can determine the current state of the server.

Status codes are basically divided into five categories, and each category is divided into a number of different sub-categories, which correspond to a lot of content. We only need to know the meaning of some common status codes.

~

Thanks for reading!

~

~

Learn interesting knowledge, make interesting friends, and create interesting souls!

Hello everyone, I am the author of “programming Samadhi” Hermit King, my public number is “programming Samadhi”, welcome to pay attention, I hope you can give me more advice!

You come, with expectations, I have the ink to greet! You return, regardless of gain and loss, only with aftertaste!

Both knowledge and skill, internal force and external work, both theory and practice should grasp, both hands should be hard!