Knowledge about http protocol that front-end developers must know

http (Hypertext Transfer Protocol) is a stateless, application-layer protocol based on request and response mode, often based on TCP connection method. This article talks about the http protocol-related knowledge that front-end developers must know. Friends who want to do front-end or are currently working on front-end must know it.

1. Concept

## http (Hypertext Transfer Protocol) is a request-and-response model based on ,

Stateless, and application layer protocols, often based on TCP connection methods. HTTP1.1 version provides a continuous connection mechanism. The vast majority of Web development is built on HTTP Web applications based on the protocol.

2. Development

Version 0.9 (only supports get) - 1.0 - 1.1 - 2.0 (under development)

Version 0.9 can only be regarded as a trial version and will not be introduced. Mainly talk about the difference between 1.0 and 1.1.

2.1 Persistent connection and non-persistent connection

Version 1.0 supports non-persistent connection, which means that it passes the TCP protocol (http is an application layer protocol based on TCP) three-way handshake After the connection is established, the server can only send one object to the browser, and then the link is disconnected. If the web page contains other inline objects, such as pictures, js files, css files, etc., multiple links need to be established, including Incurs the overhead of establishing/disconnecting multiple times. Version 1.1 supports continuous links. After a connection is established, multiple objects can be sent. Therefore, in theory, version 1.1 is more resource-saving and faster than 1.0. However, some netizens say that 1.0 is faster, which is unacceptable. Got it.

2.2 Host domain

The Host header field specifies the Internet host and port number of the requested resource, and must indicate the location of the original server or gateway of the requested URL. HTTP/1.1 requests must include the host header field, otherwise the system will return with a 400 status code. This field feels dispensable, perhaps to increase speed. After all, specifying HOST directly can find the corresponding host faster. If the host does not exist, it can also be discovered faster.

2.3 Bandwidth Optimization

Version 1.1 supports partial resource requests, and you can request only a part of the resource. At the same time, version 1.1 supports the 100 status code. When the request entity is large, you can first send the header field with the 100 status code to confirm whether the server responds to the request. If it can respond, the request entity is sent again, so that at a certain time Save bandwidth in some unresponsive situations.

Specific process: Client -Sending a request head with 100 status codes -server confirms whether it can be responding, if not, return the corresponding status code (such as 401, not authenticated). Return 100 status code - the client confirms whether to continue sending the request based on the return status code.

2.4 Request methods and status codes

HTTP1.1 adds OPTIONS, PUT, DELETE, TRACE, CONNECT and other Request methods

Only 16 are defined in HTTP/1.0 Status response codes are not specific enough for errors or warnings. HTTP/1.1 introduced a Warning header field to add a description of error or warning information.

  24 new status response codes have been added in HTTP/1.1, such as 409 (Conflict) indicating that the requested resource conflicts with the current status of the resource; 410 (Gone) indicating that a resource on the server is permanently deleted sexual deletion.

3.http communication process

(1) Query DNS according to the URL, find the web server, and establish a tcp connection with it (http lower layer agreement).

(2) Then the web browser sends a request to the server.

The request generally includes: |Request method uri http version number|Request header|Request text Example:

GET /hello.jpg HTTP/1.1

Accept:image/gif.image/jpeg

Accept-Language:zh-cn

## Connection:Keep-Alive

## Host:127.0.0.1

                                        User-Agent:Mozila/4.0(compatible;

(3) Web server response. The response package generally includes: |Protocol version status code description|Response header|Response text

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0. 12

## Date:Mon,6 Oct 2017 13:23:42 GMT

Content-Length:188

4. http header field

This part of the content is too detailed and is listed directly in the table.

Request header:

Accept-RangesAuthorization##Cache-ControlSpecify the caching mechanism followed by requests and responsesCache-Control: no-cacheConnectionIndicates whether a persistent connection is required. (HTTP 1.1 uses persistent connections by default) Connection: closeCookieWhen an HTTP request is sent, the information stored under the requested domain name will be All cookie values ​​are sent together to the web server. Cookie: $Version=1; Skin=new;Content-LengthRequested content lengthContent- Length: 348Content-TypeThe requested MIME information corresponding to the entityContent-Type: application/x-www-form- urlencodedDateThe date and time the request was sentDate: Tue, 15 Nov 2010 08:12:31 GMTExpectRequested specific server behaviorExpect: 100-continueFrom Email of the user who made the requestFrom: user@email.comHostSpecify the domain name and port number of the requested serverHost: www.zcmhi.comIf-MatchOnly the request content matches the entity is validIf-Match: "737060cd8c284d8af7ad3082f209582d"If-Modified-SinceIf the requested part is modified after the specified time, the request is successful. If it is not modified, a 304 code is returnedIf-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMTIf-None-MatchReturn 304 code if the content has not changed , the parameter is the Etag previously sent by the server, compare it with the Etag responded by the server to determine whether it has changedIf-None-Match: “737060cd8c284d8af7ad3082f209582d”If-RangeIf the entity has not changed, the server sends the missing part from the client, otherwise the entire entity is sent. The parameter is also EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”If-Unmodified-SinceOnly if the entity has not been modified after the specified time The request is successfulIf-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMTMax-ForwardsRestricted information passed Time sent by proxies and gatewaysMax-Forwards: 10PragmaUsed to contain implementation-specific instructionsPragma : no-cacheProxy-AuthorizationAuthorization certificate to connect to the proxyProxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==RangeRequest only a part of the entity, specify the rangeRange: bytes=500-999RefererThe address of the previous web page, followed by the current requested web page, that is, the source Referer: http://www.zcmhi.com/archives/71.htmlTEThe transfer encoding that the client is willing to accept, and notifies the server to accept the tail plus header informationTE: trailers,deflate;q=0.5UpgradeSpecify a transport protocol to the server for conversion (if supported) Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/ x11User-AgentThe content of User-Agent contains the information of the user who made the requestUser-Agent: Mozilla/5.0 (Linux; X11 )ViaNotify the intermediate gateway or proxy server address, communication protocolVia: 1.0 fred, 1.1 nowhere.com (Apache/1.1) WarningWarning information about the message entityWarn: 199 Miscellaneous warning

Response header:

Header	Explanation	Example
Accept	Specify the content type that the client can receive	Accept: text/plain, text/html
Accept-Charset	The browser can accept character encoding set.	Accept-Charset: iso-8859-5
Accept-Encoding	Specifies the content compression encoding type returned by the web server that the browser can support.	Accept-Encoding: compress, gzip
Accept-Language	Accept-Language: en,zh
You can request one or more sub-range fields of the web page entity	Accept-Ranges: bytes
HTTP authorization authorization certificate	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

##HeaderExplanationExampleAccept-RangesIndicates whether the server supports the specified range request and which type of segmented requestAccept-Ranges: bytesAgeEstimated time in seconds from origin server to proxy cache formation Age: 12 AllowA valid request behavior for a certain network resource. If not allowed, 405Allow: GET, HEADCache-Control## will be returned. Content-EncodingContent-LanguageContent-LengthContent-Location Content-MD5##Content-RangeIn this part of the entire return body Byte positionContent-Range: bytes 21010-47021/47022Content-TypeReturn the MIME type of the contentContent-Type: text/html; charset=utf-8DateThe time when the original server message was sentDate: Tue, 15 Nov 2010 08:12:31 GMTETagThe current value of the entity tag of the request variableETag: "737060cd8c284d8af7ad3082f209582d"ExpiresResponse expiration date and timeExpires: Thu, 01 Dec 2010 16:00:00 GMTLast-ModifiedThe last modification time of the requested resourceLast-Modified: Tue, 15 Nov 2010 12:45:26 GMT Location is used to redirect the recipient to the location of the non-requested URL to complete the request or identify a new resourceLocation: http://www.zcmhi.com/archives/94.html PragmaIncludes implementation-specific directives that can be applied to any receiver on the response chainPragma: no-cacheProxy-AuthenticateIt indicates the authentication scheme and parameters on that URL that can be applied to the proxy Proxy-Authenticate: BasicrefreshApply to redirect or a new resource is created, redirect after 5 seconds (proposed by Netscape, supported by most browsers)Retry-AfterIf the entity is temporarily unavailable, notify the client to try again after the specified time Retry-After: 120Serverweb server software nameServer: Apache/1.3.27 (Unix) (Red-Hat/Linux) Set-CookieSet Http CookieSet-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1Indicates that the header field exists at the end of the chunked transfer encodingFile transfer encoding Tell the downstream proxy whether to use a cached response or request from the origin serverInform the proxy where the client response was sentWarning entity may have problemsIndicates the authorization scheme that the client requesting entity should use

#Tell all caching mechanisms whether they can be cached and of what type

Cache-Control: no-cache

The returned content compression encoding type supported by the web server.

Content-Encoding: gzip

The language of the response body

Content-Language: en,zh

The length of the response body

Content-Length: 348

Request an alternative address for the resource

Content-Location: /index.htm

Return the MD5 check value of the resource

Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Refresh: 5; url=

http://www.zcmhi.com/archives/94.html

##Trailer

Trailer: Max-Forwards

Transfer-Encoding

Transfer-Encoding:chunked

Vary

Vary: *

Via

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning

Warning: 199 Miscellaneous warning

WWW- Authenticate

WWW-Authenticate: Basic

5. http request method

GET Request to obtain the resource identified by Request-URI
POST In the resource identified by Request-URI Append new data after the resource
HEAD Request to obtain the response message header of the resource identified by Request-URI
PUT Request the server to store a resource and use Request-URI as its identifier
DELETE Request the server to delete Request- The resource identified by the URI
TRACE Requests the server to send back the received request information, mainly used for testing or diagnosis
CONNECT Reserved for future use
OPTIONS Request to query the performance of the server, or query the options and requirements related to the resource

6. Status code

#Response The first line in the message is called the status line, which consists of the HTTP protocol version number and the status code , the status message consists of three parts.

The status code is used to tell the HTTP client whether the HTTP server has generated the expected Response.

HTTP/1.1 defines 5 types of status codes. The status code consists of three digits. A number defines the category of the response

　1XX Prompt message - Indicates that the request has been successfully received and continues to be processed, indicating that data needs to continue to be received to complete the request.

2XX Success - Indicates that the request has been successfully received, understood, and accepted

3XX Redirect - Further processing must be performed to complete the request

4XX Client Error - Request There is a syntax error or the request cannot be implemented

5XX Server-side error - The server failed to implement a legal request

Status code list

Table 1 (brief introduction table, introduction introduction It is concise and clear. It is recommended to check this table first. If you don’t understand, check the following table 2)

##303See Other to view other addresses. Similar to 301. Use GET and POST requests to view 304Not ModifiedNot modified. The requested resource has not been modified. When the server returns this status code, no resource will be returned. Clients typically cache accessed resources by providing a header indicating that the client wishes to return only resources modified after a specified date305Use ProxyUse a proxy. The requested resource must be accessed through a proxy306UnusedDeprecated HTTP status code307Temporary RedirectTemporary redirection. Similar to 302. Use GET requests to redirect status codes starting with 4400Bad Requestcustomers The syntax of the request is incorrect and the server cannot understand it401UnauthorizedThe request requires user authentication402Payment RequiredReserved for future use403ForbiddenThe server understands The client's request was requested, but the request was refused to be executed 404Not FoundThe server could not find the resource (webpage) based on the client's request. With this code, website designers can set up a personalized page that says "The resource you requested could not be found"405Method Not AllowedCustomers The method in the client request is prohibited406Not AcceptableThe server cannot complete the request based on the content characteristics of the client request407Proxy Authentication RequiredThe request requires proxy authentication, similar to 401, but the requester should use the proxy for authorization408Request Time-outThe server waited too long for the request sent by the client and timed out409ConflictThe server may return this code when completing the client's PUT request. A conflict occurred when the server processed the request410GoneThe resource requested by the client no longer exists. 410 is different from 404. If the resource has been permanently deleted, the 410 code can be used. The website designer can specify the new location of the resource through the 301 code411 Length RequiredThe server cannot process the request information sent by the client without Content-Length412Precondition Failed Prerequisite error for client request information413Request Entity Too LargeRejected because the requested entity is too large and cannot be processed by the server ask. To prevent continued requests from the client, the server may close the connection.If it is just that the server cannot process it temporarily, it will contain a Retry-After response message

Status code	Status code English name	Chinese description
Status codes starting with 1
100	Continue	continue. The client should continue its request
101	Switching Protocols	Switching protocols. The server switches protocols based on the client's request. You can only switch to a higher-level protocol, for example, switch to a new version of HTTP protocol
2 with a status code starting with
200	OK	The request was successful. Generally used for GET and POST requests
201	Created	has been created. Successfully requested and created a new resource
202	Accepted	Accepted. The request has been accepted but has not been processed
203	Non-Authoritative Information	Non-authorized information. The request was successful. But the meta information returned is not on the original server, but a copy
204	No Content	No content. The server processed successfully, but no content was returned. Ensures that the browser continues to display the current document without updating the web page
205	Reset Content	Reset content. Server processing is successful and the user terminal (e.g. browser) should reset the document view. This return code can be used to clear the browser's form field
206	Partial Content	partial content. The server successfully processed some GET requests. Status codes starting with
3 are
300	Multiple Choices	multiple choices. The requested resource may include multiple locations, and accordingly a list of resource characteristics and addresses may be returned for user terminal (e.g. browser) selection
301	Moved Permanently	Move permanently. The requested resource has been permanently moved to the new URI, the return information will include the new URI, and the browser will automatically be directed to the new URI. Any new requests in the future should use the new URI instead of
302	Found	Temporarily Moved. Similar to 301. But the resource is only moved temporarily. The client should continue to use the original URI
414	Request-URI Too Large	Requested URI Too long (URI is usually a URL) and the server cannot handle it
415	Unsupported Media Type	The server cannot process the media format attached to the request
416	Requested range not satisfiable	The range requested by the client is invalid
417	Expectation Failed	The server cannot satisfy the status code starting with Expect request header information
5
500	Internal Server Error	Internal server error, unable to complete the request
501	Not Implemented	The server does not support The requested function cannot complete the request
502	Bad Gateway	The server acting as a gateway or proxy received an invalid request from the remote server. Request
503	Service Unavailable	Due to overload or system maintenance, the server is temporarily unable to process the client's request. The length of the delay can be included in the server's Retry-After header information
504	Gateway Time-out	Server acting as a gateway or proxy , the request was not obtained from the remote server in time
505	HTTP Version not supported	The server does not support the requested HTTP protocol version and cannot be completed deal with

Table 2 Detailed introduction table

##100The client should continue send request. This provisional response is used to inform the client that part of its request has been received by the server and has not yet been rejected. The client SHOULD continue sending the remainder of the request, or ignore this response if the request has already been completed. The server must send a final response to the client after the request is completed. 101The server has understood the client's request and will notify the client through the Upgrade message header to use a different protocol to complete the request. After sending the last blank line of this response, the server will switch to the protocols defined in the Upgrade header. Similar measures should only be taken when it would be more beneficial to switch to a new protocol. For example, there are advantages to switching to a new HTTP version over an older version, or switching to a real-time and synchronous protocol for delivering resources that take advantage of such features. 102 Status code extended by WebDAV (RFC 2518), indicating that processing will continue. 200The request has been successful, and the response header or data body expected by the request will be returned with this response. 201The request has been fulfilled, and a new resource has been created based on the request's needs, and its URI has been returned with the Location header information. If the required resources cannot be created in time, '202 Accepted' should be returned. 202The server has accepted the request but has not yet processed it. Just as it may be denied, the request may or may not ultimately be executed. In the case of asynchronous operations, there is no more convenient way than sending this status code. The purpose of returning a 202 status code response is to allow the server to accept requests from other processes (such as a batch-based operation that is only performed once a day) without having to keep the client connected to the server until the batch operation is completed. A response that accepts request processing and returns a 202 status code should contain some information in the returned entity indicating the current status of the processing, as well as a pointer to a processing status monitor or status prediction so that the user can estimate whether the operation has been completed. 203The server has successfully processed the request, but the entity header metainformation returned is not a determined set that is valid on the original server, but comes from local or third party Third party copy. The current information may be a subset or a superset of the original version. For example, containing metadata for a resource may cause the origin server to know the super information about the metadata. Using this status code is not required and is only appropriate if the response would have returned 200 OK without this status code. 204The server successfully processed the request, but does not need to return any entity content, and hopes to return updated meta information. The response may return new or updated metainformation in the form of entity headers. These headers, if present, should correspond to the requested variables. If the client is a browser, the user's browser SHOULD retain the page for which the request was made without any changes to the document view, even if new or updated metainformation should be applied to the user's browser activity according to the specification Documents in view. Since a 204 response is prohibited from containing any message body, it always ends with the first blank line after the message header. 205The server successfully processed the request and returned nothing. But unlike a 204 response, a response returning this status code requires the requester to reset the document view. This response is mainly 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 prohibited from containing any message body and ends with the first blank line after the message header. 206The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Thunder use this type of response to resume interrupted downloads or break a large document into multiple download segments for simultaneous downloading. The request must include a Range header to indicate the range of content the client wishes to obtain, and may include an If-Range as a request condition. The response must include the following header fields: Content-Range is used to indicate the range of content returned in this response; if it is a multi-part download with Content-Type multipart/byteranges, each multipart Each paragraph should contain a Content-Range field to indicate the content range of this paragraph. If a Content-Length is included in the response, its value must match the actual number of bytes in 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 its value may be different from the value corresponding to other previous responses to the same variable.If this response request uses If-Range strong cache verification, then this response should not contain other entity headers; if this response request uses If-Range weak cache validation, then this response is prohibited from containing other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response should contain all entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers do not match exactly, the client cache should not combine the content returned by the 206 response with any previously cached content. Any cache that does not support the Range and Content-Range headers is prohibited from caching the content returned by the 206 response.

Status Code	Meaning
207	Status code extended by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message, and may vary according to the number of previous sub-requests , containing a series of independent response codes.
300	The requested resource has a series of optional responses, each with its own specific address and browser driver negotiation information. The user or browser can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity with a list of resource attributes 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 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 be performed. If the server itself already has a preferred feedback option, then in The Location should indicate the URI of this feedback; the browser may use this Location value as the address for automatic redirection. Additionally, this response is cacheable unless otherwise specified.
301	The requested resource has been permanently moved to a new location, and any future references to this resource should use one of several URIs returned with this response . If possible, clients with link editing capabilities should automatically modify the requested address to the address returned from the server. Unless otherwise specified, this response is also cacheable. The new persistent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, because the conditions of the request may change accordingly. Note: For some browsers using the HTTP/1.0 protocol, when the POST request they send receives a 301 response, the subsequent redirect request will become a GET method.
302	The requested resource now temporarily responds to requests from a different URI. Because such redirects are temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, because the conditions of the request may change accordingly. Note: Although RFC The 1945 and RFC 2068 specifications do not allow the client to change the request method when redirecting, but many existing browsers regard the 302 response as a 303 response, and use the GET method to access the URI specified in the Location, regardless of the original request method. . Status codes 303 and 307 were added to clarify what response the server expects from the client.
303	The response corresponding to the current request can be found at another URI, and the client should use GET to access that resource. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not a replacement reference to the original resource. At the same time, 303 responses are prohibited from being cached. Of course, the second request (redirect) might be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. NOTE: Many pre-HTTP/1.1 browsers do not correctly understand the 303 status. If you need to consider interaction with these browsers, the 302 status code should be sufficient, because most browsers handle 302 responses exactly the way the above specification requires the client to handle 303 responses.
304	If the client sends a conditional GET request and the request is allowed, and the content of the document (since the last access or according to the request condition) has not changed, the server should return this status code. A 304 response is prohibited from including a message body, so it always ends with the first blank line after the message header.The response MUST contain the following header information: Date, unless the server does not have a clock. If servers without clocks follow these rules, then proxy servers and clients can add the Date field to received response headers themselves (as specified in RFC 2068), and the caching mechanism will work normally. ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if its value may be different from the value corresponding to other previous responses to the same variable. If this response request uses strong cache verification, then this response should not contain other entity headers; otherwise (for example, a conditional GET request uses weak cache verification), this response is prohibited from containing other entity headers; this avoids Resolves inconsistencies between cached entity content and updated entity header information. If a 304 response indicates that an entity is not currently cached, the caching system must ignore the response and repeat the request without the restriction. If a 304 response is received that requires an update to a cache entry, the cache system must update the entire entry to reflect the values ​​of all fields that were updated in the response.
305	The requested resource must be accessed through the specified proxy. The Location field will give the URI information where the specified proxy is located. The recipient needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only the origin server can establish a 305 response. Note: RFC 2068 does not specify that a 305 response is intended to redirect a single request and can only be established by the origin server. Ignoring these restrictions can lead to serious safety consequences.
306	In the latest version of the specification, the 306 status code is no longer used.
307	The requested resource now temporarily responds to requests from a different URI. Because such redirects are temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Because some browsers do not recognize the 307 response, the above necessary information needs to be added so that users can understand and make access requests to the new URI. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, because the conditions of the request may change accordingly.
400	1. The semantics are incorrect and the current request cannot be understood by the server. The client should not resubmit this request unless modified. 2. The request parameters are incorrect.
401	The current request requires user authentication. The response MUST include a WWW-Authenticate header appropriate to the requested resource that asks for user information. The client can repeatedly submit a request containing the appropriate Authorization header. If the current request already included Authorization certificates, the 401 response indicates that the server verification has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has attempted authentication at least once, the browser should display the entity information contained in the response to the user, because this entity information may contain relevant diagnostic information . See RFC 2617.
402	This status code is reserved for possible future needs.
403	The server understood the request, but refused to execute it. Unlike a 401 response, authentication does not provide any help, and the request should not be resubmitted. If this is not a HEAD request and the server wants to be able to explain why the request cannot be executed, then the reason for the rejection should be described in the entity. Of course, the server can also return a 404 response if it does not want the client to obtain any information.
404	The request failed. 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 the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism problems, and there is no jump address. The 404 status code is widely used when the server does not want to reveal why the request was rejected or no other suitable response is available.
405	The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header information to indicate the list of request methods that the current resource can accept. Since the PUT and DELETE methods will write resources on the server, most web servers do not support or do not allow the above request methods under the default configuration, and a 405 error will be returned for such requests.
406	The content characteristics of the requested resource cannot 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 a list of entity attributes and addresses from which the user or browser can choose the most appropriate. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make its own best choice based on the format and its capabilities. However, the specification does not define any criteria for making such automatic selections.
407	is similar to the 401 response, except that the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate for identity queries. The client can return a Proxy-Authorization header for verification. See RFC 2617.
408	The request timed out. The client did not complete sending a request within the time the server was prepared to wait. The client can resubmit this request at any time without making any changes.
409	The request cannot be completed due to a conflict with the current state of the requested resource. This code should only be used if the user is believed to be able to resolve the conflict and resubmit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in an environment using version checking, if the version information attached to a modification request for a specific resource submitted by a PUT conflicts with a previous (third-party) request, then the server should return a 409 error at this time. Inform the user that the request cannot be completed. At this time, the response entity is likely to contain a difference comparison between the two conflicting versions, so that the user can resubmit the new version after merging.
410	The requested resource is no longer available on the server and does not have any known forwarding address. Such a situation should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address with the user's permission. If the server does not know or cannot determine whether the condition is permanent, then the 404 status code should be used. Unless otherwise noted, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the website, notify users that the resource is no longer available, and the server owner hopes that all remote connections pointing to this resource will also be deleted. This type of incident is common among limited-time, value-added services. Similarly, the 410 response is also used to notify the client that resources originally belonging to an individual are no longer available on the current server site. Of course, do you need to mark all permanently unavailable resources as '410' Gone', and whether or not this mark needs to be maintained for how long, is entirely up to the server owner.
411	The server refused to accept the request without defining the Content-Length header. After adding a valid Content-Length header indicating the length of the request message body, the client can submit the request again.
412	The server failed to satisfy one or more of the prerequisites given in the header fields of the request. This status code allows the client to set preconditions in the request metainformation (request header field data) when retrieving the resource, thereby preventing the request method from being applied to the resource other than what it expects.
413	The server refuses to process the current request because the size of the entity data submitted by the request exceeds what the server is willing or able to handle. In this case, the server can close the connection to prevent the client from continuing to send this request. If the situation is temporary, the server should return a Retry-After response header to inform the client how long it can wait to try again.
414	The requested URI is longer than the server can interpret, so the server refuses to service the request. This is relatively rare. Common situations include: The form submission that should have used the POST method becomes the GET method, causing the query string to be too long. Redirect URI "black hole", for example, each redirection uses the old URI as part of the new URI, resulting in an overlong URI after several redirections. The client is trying to exploit the security holes in some servers to attack the server. This type of server uses a fixed-length buffer to read or operate the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code.
415	For the current request method and the requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected.
416	If the request contains the Range request header, and any data range specified in the Range does not coincide with the available range of the current resource, and the request contains If the If-Range request header is not defined, the server should return a 416 status code.If Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Range entity header to indicate the length of the current resource while returning the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type.
417	The expected content specified in the request header Expect cannot be met by the server, or the server is a proxy server and it has obvious evidence that it is not used in the current route. On the next node, the content of Expect cannot be satisfied.
421	The number of connections to the server from the current client's IP address exceeds the maximum allowed range of the server. Usually, the IP address here refers to the client address seen from the server (such as the user's gateway or proxy server address). In this case, the connection count may involve more than one end user.
422	The number of connections to the server from the current client's IP address exceeds the maximum allowed range of the server. Usually, the IP address here refers to the client address seen from the server (such as the user's gateway or proxy server address). In this case, the connection count may involve more than one end user.
422	The request format is correct, but it cannot respond due to semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
424	The current request failed due to an error that occurred in a previous request, such as PROPPATCH. (RFC 4918 WebDAV)
425	Defined in the WebDav Advanced Collections draft, but does not appear in the WebDAV Sequence Collection Protocol (RFC 3658).
426	Clients should switch to TLS/1.0. (RFC 2817)
449	Extended by Microsoft, indicates that the request should be retried after performing the appropriate action.
500	The server encountered an unexpected condition that prevented it from completing processing of the request. Generally speaking, this problem will occur when there is an error in the server's program code.
501	The server does not support a feature required by the current request. When the server does not recognize the requested method and cannot support its request for any resource.
502	A server working as a gateway or proxy received an invalid response from the upstream server when trying to perform a request.
503	The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will be restored after a period of time. If a delay can be expected, the response can include a Retry-After header to indicate the delay. If this Retry-After message is not given, the client SHOULD handle it the same way it handles a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers simply wish to deny connections from clients.
504	When a server working as a gateway or proxy tries to execute a request, it fails to obtain the request in time from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP ) or a secondary server (e.g. DNS) receives a response. Note: Some proxy servers will return a 400 or 500 error when a DNS query times out
505	The server does not support, or refuses to support, the HTTP version used in the request . This implies that the server is unable or unwilling to use the same version as the client. The response should contain an entity describing why the version is not supported and what protocols the server supports.
506	Extended by the "Transparent Content Negotiation Protocol" (RFC 2295), indicating that the server has an internal configuration error: the requested negotiation argument resource is configured to be in Uses itself in transparent content negotiation and is therefore not an appropriate focus in a negotiation process.
507	The server cannot store the content necessary to complete the request. This condition is considered temporary. WebDAV (RFC 4918)
509	The server has reached its bandwidth limit. This is not an official status code, but is still widely used.
510	The strategies required to obtain resources are not met. (RFC 2774)

Finally, most of the information is collected from the Internet. Thank you to all the senior colleagues who contributed!

[Recommended course: http video tutorial]

The above is the detailed content of Knowledge about http protocol that front-end developers must know. For more information, please follow other related articles on the PHP Chinese website!