Http status code list

100 The client should continue sending requests. This provisional response is used to inform the client that part of its request has been received by the server and has not been rejected. The client SHOULD continue sending the remainder of the request, or ignore this response if the request has already 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 through the Upgrade header to use a different protocol to complete the request. After sending the blank line at the end of this response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when it is more beneficial to switch to a new protocol. For example, switching to a new HTTP version has advantages over older versions, or switching to a real-time and synchronous protocol for delivering resources that take advantage of such features.

200 The request was successful, and the response headers or data bodies expected by the request will be returned with this response.

400 1 Semantic error The current request cannot be understood by the server. The client SHOULD NOT submit this request repeatedly unless modified. 2. The request parameters are incorrect.


401 The current request requires user authentication. The response MUST contain a WWW-Authenticate header appropriate for the requested resource to ask the user for information. The client MAY resubmit a request with the appropriate Authorization headers. If the current request already contains Authorization certificates, then a 401 response means that the server verified that those certificates have been rejected. If the 401 response contains the same authentication challenge as the previous response, and the browser has attempted at least one authentication, the browser SHOULD present the user with the entity information contained in the response, which may contain relevant diagnostic information . See RFC 2617.

402 The code is reserved for possible future needs

403 The server understood the request, but refused to execute it. Unlike a 401 response, authentication doesn't help, and the request shouldn't be resubmitted. If this is not a HEAD request, and the server wishes to be able to articulate why the request could not be performed, then the reason for the rejection should be described within the entity. Of course the server can also return a 404 response if it doesn't want the client to get 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 about the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism problem, and 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 when 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 indicating the list of request methods that the current resource can accept. In view of the PUT and DELETE methods, the resources on the server will be written, so most web servers do not support or do not allow the above request methods under the default configuration. For such requests, 405 error

406 The requested resource will be returned. The content attribute could not satisfy the condition in the request header, so the response entity could not be generated. Unless this is a HEAD request, the response SHOULD return an entity containing a list of attributes and addresses from which the user or browser can choose the most appropriate entity. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice on its own based on the format and its own capabilities. However, the specification does not define any criteria for making such automatic selections.

A 407 is similar to a 401 response, except that the client must authenticate on the proxy server. The proxy server MUST return a Proxy-Authenticate for identity queries. The client MAY return a Proxy-Authorization header for authentication. See RFC 2617.

408 Request timed out. The client did not complete a request within the time the server was prepared to wait. The client MAY resubmit this request at any time without making 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 to be used if the user is considered able to resolve the conflict and will 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 where version checking is used, 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 could not be completed. At this point, the response entity is likely to contain a diff comparison between the two conflicting versions, so that the user resubmits the new version after the merge.

500 The server encountered an unexpected condition that prevented it from completing the request. Generally speaking, this problem will occur when the server's program code is wrong

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

502 An invalid response was received from an upstream server when a server working as a gateway or proxy attempted to perform the request

503 The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will return after a period of time. If the delay time can be expected, the response MAY include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client SHOULD handle it with a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when overloaded. Some servers simply wish to reject the client's connection.

504 The server working as a gateway or proxy failed to receive a timely response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the secondary server (such as DNS) when trying to execute the request. Note: Some proxy servers will return a 400 or 500 error 505 when a DNS query times out, the

server does not support it, 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 contain 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) to indicate that the server has an internal configuration error: the requested negotiation argument resource is configured as Uses itself in transparent content negotiation and thus is 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 Server reaches bandwidth limit. This is not an official status code, but still widely used

510 The strategy required to obtain resources is not unsatisfied. (RFC 2774)