|
HTTP -код статусу
|
Значення коду статусу
|
|
100
|
The client should continue to send requests. This temporary response is used to notify the client that part of its request has been received by the server and has not yet been rejected. The client should continue to send the rest of the request, or ignore the response if the request has completed. The server must send a final response to the client after the request is complete. |
|
101
|
The server has understood the client's request and will notify the client to use a different protocol to complete the request through the Upgrade message header. After sending the last blank line in this response, the server will switch to those protocols defined in the Upgrade message header.
Similar steps should only be taken if switching to a new protocol is more beneficial. For example, switching to the new HTTP version has advantages over the old version, or switching to a real-time and synchronous protocol to transfer resources that take advantage of such features.
|
|
102
|
A status code extended by WebDAV (RFC 2518) to indicate that processing will continue.。
|
|
200
|
The request was successful, and the requested response header or data body will be returned with this response.
|
|
201
|
The request has been fulfilled, and a new resource has been created based on the request, and its URI has been returned with the Location header. If the required resources cannot be established in time, it should return '202 Accepted'.
|
|
202
|
The server has accepted the request but has not yet processed it. Just as it may be rejected, the request may or may not be executed in the end. In the case of asynchronous operation, there is no more convenient way than sending this status code. The purpose of the response that returns a 202 status code is to allow the server to accept requests from other processes (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. Responses that accept a request for processing and return a 202 status code should include some information in the returned entity that indicates the current status of the processing, and a pointer to the processing status monitor or status prediction, so that the user can estimate whether the operation has completed.
|
|
203
|
The server has successfully processed the request, but the entity header meta information returned is not a deterministic set 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, containing metadata for a resource may cause the origin server to know the meta information super. It is not necessary to use this status code, and it will return 200 only if the response does not use this status code.
The case is OK.
|
|
204
|
The server successfully processed the request, but did not need to return any entity content, and wanted to return updated meta information. The response may return new or updated meta information in the form of an entity header. If these headers are present, they should correspond to the requested variables.
If the client is a browser, then the user's browser should retain the page that sent the request without any changes in the document view, even if new or updated meta-information should be applied to user browser activities Document in view.
Since the 204 response is forbidden to contain any message body, it always ends with the first blank line after the message header.
|
|
205
|
The server successfully processed the request and did not return anything. But unlike the 204 response, a response that returns 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, the response is also prohibited from containing any message body and ends with the first blank line after the message header.
|
|
206
|
The server has successfully processed some GET requests. HTTP download tools such as FlashGet or Thunder use this type of response to implement breakpoint resumption or to break a large document into multiple download segments for simultaneous download.
The request must include the Range header to indicate the range of content the client wants, and may include If-Range as the 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-segment download with Content-Type of multipart / byteranges, each multipart segment should include Content-Range Domains are used to indicate the scope of this paragraph. If the response contains Content-Length, its value must match the true 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 their values may be different from the corresponding values of other responses of the same variable before.
If this response request uses If-Range strong cache verification, then this response should not include other entity headers; if this response request uses If-Range weak cache verification, then this response must not include other entity headers; this avoids Inconsistency between cached entity content and updated entity header information. Otherwise, this response should include all entity header fields that should be returned in the 200 response.
If the ETag or Last-Modified header cannot 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.
|
|
207
|
The status code extended by WebDAV (RFC 2518) represents that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests.
|
|
300
|
The requested resource has a series of optional feedback information, each with its own specific address and browser-driven 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 characteristics and addresses so that the user or browser can choose the most appropriate redirection address from it. 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. RFC, of course
The 2616 specification does not specify how such an automatic selection should proceed. If the server itself already has the preferred feedback option, the Location URI should be indicated in the Location; browsers may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable.
|
|
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 in this response. If possible, clients with link editing capabilities should automatically change the requested address to the address returned from the server. Unless otherwise specified, this response is also cacheable.
The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should include a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser will not automatically redirect unless the user confirms it, because the conditions of the request may change accordingly.
Note: For some browsers using the HTTP / 1.0 protocol, when they send a 301 response to the POST request, the next redirection request will become GET.
|
|
302
|
The requested resource now temporarily responds to the request from a different URI. Since this redirection is 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 include a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is confirmed by the user, because the conditions of the request may change accordingly.
Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request during redirection, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location, regardless of the URI. The method originally requested. Status codes 303 and 307 have been added to clarify what the server expects the client to do.
|
|
303
|
The response corresponding to the current request can be found on another URI, and the client should use GET to access that resource. This method exists mainly to allow redirection of the output of a POST request activated by a script to a new resource. This new URI is not a replacement reference to the original resource. At the same time, the 303 response is prohibited from being cached. Of course, the second request (redirect) may 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 include a hyperlink to the new URI and a short description. Note: Many browsers prior to HTTP / 1.1 did not understand the 303 status correctly. If you need to consider interaction with these browsers, the 302 status code should be adequate, because most browsers handle the 302 response exactly as the above specification requires the client to do when processing the 303 response.
|
|
304
|
If the client sends a conditional GET request and the request has been allowed, and the content of the document (since the last visit or according to the conditions of the request) has not changed, the server should return this status code. The 304 response is prohibited from including the message body, so it always ends with the first blank line after the message header.
The response must include the following headers: Date, unless this server has no clock. If a server without a clock also adheres to these rules, the proxy server and the client can add the Date field to the received response header (as RFC
2068), the caching mechanism will work normally. ETag and / or Content-Location, if the same request should have returned 200 responses. Expires, Cache-Control, and / or Vary, if their values may be different from the corresponding values of other responses of the same variable before.
If this response request uses strong cache authentication, then this response should not include other entity headers; otherwise (for example, a conditional GET request uses weak cache authentication), this response is prohibited from including other entity headers; this avoids Inconsistencies between cached entity content and updated entity header information.
If a 304 response indicates that an entity is not currently cached, the cache system must ignore the response and repeatedly send requests that do not contain restrictions. If a 304 response is received that requires a cache entry to be updated, the cache system must update the entire entry to reflect the values of all the fields that were updated in the response.
|
|
305
|
The requested resource must be accessible through the specified proxy. The Location field will give the URI information of the specified proxy. The receiver needs to send a separate request repeatedly to access the corresponding resource through this proxy. Only the origin server can establish a 305 response.
Note: There is no explicit 305 response in RFC 2068 to redirect a single request, and it can only be established by the origin server. Ignoring these restrictions can lead to serious security 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 the request from a different URI. Since this redirection is 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 include a hyperlink to the new URI and a short description. Because some browsers cannot recognize the 307 response, it is necessary to add the above necessary information so that the user can understand and issue an access request to the new URI.
If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is 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. Unless modified, the client should not submit this request repeatedly. 2. The request parameters are incorrect.
|
|
401
|
User authentication is required for the current request. The response must include a WWW-Authenticate header suitable for the requested resource to ask the user for information. The client can repeatedly submit a request with the appropriate Authorization header. If the current request already contains Authorization certificates, then the 401 response means that the server verifies that those certificates have been rejected. If the 401 response contains the same authentication challenge as the previous response, and the browser has tried authentication at least once, the browser should show 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 has understood the request, but refused to execute it. Unlike the 401 response, authentication does not provide any help, and this 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 get any information.
|
|
404
|
The request failed, and the requested resource was not found on the server. There is no information to tell the user whether the situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform the old resource that it is permanently unavailable due to some internal configuration mechanism problems, and there is no address that can be jumped to. 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 to indicate the list of request methods that the current resource can accept. In view of PUT, the DELETE method writes resources on the server, so most web servers do not support or do not allow the above request methods in the default configuration, and will return 405 errors for such requests.
|
|
406
|
The content characteristics of the requested resource cannot meet the conditions in the request header, so a response entity cannot be generated. Unless this is a HEAD request, the response should return an entity containing a list of entity properties and addresses from which the user or browser can select the most appropriate. 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 selections.
|
|
407
|
Similar to the 401 response, except that the client must authenticate on the proxy server. The proxy server must return a Proxy-Authenticate for identity inquiry. The client can return a Proxy-Authorization header for verification. See RFC
2617.
|
|
408
|
Request timed out. The client did not complete the sending of a request within the time the server was prepared to wait. The client can resubmit this request at any time without any changes.
|
|
409
|
The request could not be completed due to a conflict with the current state of the requested resource. This code is only allowed in cases where the user is considered to be able to resolve the conflict and will resubmit a new request. The response should contain enough information for users to discover the source of the conflict.
Collisions usually occur in the processing of PUT requests. For example, in a version checking environment, the version information attached to a specific resource modification request submitted by a PUT conflicts with a previous (third-party) request, then the server should return a 409 error at this time. Inform users that the request could not be completed. At this point, the response entity is likely to include a comparison of the differences 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 there are no known forwarding addresses. Such a situation should be considered permanent. If possible, clients with link editing capabilities should delete all references to this address after obtaining user permission. If the server does not know or is unsure whether this condition is permanent, then a 404 status code should be used. Unless otherwise specified, this response is cacheable.
The purpose of the 410 response is mainly to help the webmaster maintain the website, notify the user that the resource is no longer available, and the server owner wants all remote connections to this resource to be deleted. Such incidents are common in time-limited, value-added services. Similarly, the 410 response is also used to notify the client on the current server site that resources originally belonging to an individual are no longer available. Of course, is it necessary to mark all permanently unavailable resources as' 410
Gone ', and how long this tag needs to be kept, is entirely up to the server owner.
|
|
411
|
The server refuses to accept the request without defining a 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 these when verifying that the prerequisites were given in the header field of the request. This status code allows the client to set prerequisites in the requested meta-information (request header field data) when acquiring the resource, so as to prevent the request method from being applied to resources other than its desired content.
|
|
413
|
The server refused to process the current request because the size of the entity data submitted by the request exceeded what the server was willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send this request. If this condition is temporary, the server should return a Retry-After response header to inform the client how many times it can try again later.
|
|
414
|
The request URI exceeds the length that the server can interpret, so the server refuses to service the request. This is relatively rare, and the usual situations include: Form submissions that should have used the POST method become GET methods, resulting in query strings (Query
String) is too long. Redirection URI "black holes", for example, each redirect uses the old URI as part of the new URI, resulting in a long URI after several redirects. The client is trying to attack the server with a security vulnerability in some servers. This type of server uses a fixed-length buffer to read or manipulate the URI of the request. 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 currently requested method and requested resource, the entity submitted in the request is not a format supported in the server, so the request is rejected.
|
|
416
|
If the request includes a Range request header, and any data range specified in the Range does not coincide with the available range of the current resource, and the If-Range request header is not defined in the request, 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 return a 416 status code and include a Content-Range entity header to indicate the length of the current resource. 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 satisfied by the server, or the server is a proxy server, and it has clear evidence that the content of Expect cannot be satisfied on the next node of the current route.
|
|
421
|
The number of connections from the current client's IP address to the server exceeded the maximum range allowed by the server. Generally, the IP address here refers to the client address (such as the user's gateway or proxy server address) as seen from the server. In this case, the calculation of the number of connections may involve more than one end user.
|
|
422
|
The number of connections from the current client's IP address to the server exceeded the maximum range allowed by the server. Generally, the IP address here refers to the client address (such as the user's gateway or proxy server address) as seen from the server. In this case, the calculation of the number of connections may involve more than one end user.
|
|
422
|
The request is formatted correctly, but cannot respond because it contains a semantic error. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
|
|
424
|
The current request failed due to an error 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 Set Protocol (RFC 3658).
|
|
426
|
The client should switch to TLS / 1.0. (RFC 2817)
|
|
449
|
Extended by Microsoft, a representative request should retry after performing the appropriate action.
|
|
500
|
The server encountered an unexpected condition that prevented it from completing the request. In general, this problem occurs when the program code of the server is wrong.
|
|
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
|
When a server working as a gateway or proxy tried to execute a request, it received an invalid response from an upstream server.
|
|
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 the delay time can be estimated, 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 in the same way as a 500 response.
Note: The presence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers simply want to reject client connections.
|
|
504
|
When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the auxiliary server (such as DNS) in a timely manner.
Note: Some proxy servers return a 400 or 500 error when the 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 cannot or does not want to use the same version as the client. The response should include an entity describing why the version is not supported and which protocols the server supports.
|
|
506
|
Extended by the Transparent Content Negotiation Protocol (RFC 2295), representing an internal configuration error on the server: The requested negotiation argument resource is configured to use itself in transparent content negotiation, so it is not an appropriate focus in a negotiation process.
|
|
507
|
The server cannot store the content necessary to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
|
|
509
|
The server reached a bandwidth limit. This is not an official status code, but it is still widely used.
|
|
510
|
The strategy required to obtain resources is not unsatisfactory. (RFC 2774)
|
