Similar to HTTP download tools like FlashGet or Thunder, all use this type of response to implement resumable downloads or split a large document into multiple download segments for simultaneous download.

This request must include Range header information to indicate the content range that the client wants to get, and may include If-Range as a request condition.

The response must include the following header fields:

• Content-Range is used to indicate the content range returned in this response; if it is a multi-segment download with Content-Type as multipart/byteranges, then each multipart segment should contain a Content-Range field to indicate the content range of this segment. If the response contains Content-Length, then 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 their values might be different from the values corresponding to other responses of the same variable previously.

If this response request uses If-Range strong cache validation, 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 inconsistency 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 cannot be exactly matched, then the client cache should prohibit combining the content returned by the 206 response with any previously cached content.

Any cache that does not support Range and Content-Range headers is prohibited from caching the content returned by a 206 response.

The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the several URIs returned by this response. If possible, clients with link editing functionality should automatically modify the request address to the address fed back from the server. Unless otherwise specified, this response is also cacheable.

The new permanent URI should be returned in the response's Location field. 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, browsers are therefore prohibited from automatically redirecting unless user confirmation is obtained, because the request conditions may change as a result.

Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and get a 301 response, the subsequent redirect request will become a GET method.

The requested resource now temporarily responds to requests from a different URI. Since such redirects are temporary, clients 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 response's Location field. 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, then browsers are prohibited from automatically redirecting unless user confirmation is obtained, because the request conditions may change as a result.

The existence of this method is mainly to allow POST request output activated by scripts to redirect to a new resource. This new URI is not a substitute reference for the original resource.

Similar to 302, but the 307 status code does not allow browsers to redirect an originally POST request to a GET request.

Similar to 301, but the 308 status code does not allow browsers to redirect an originally POST request to a GET request.

304 responses are prohibited from containing a message body, so they always end with the first blank line after the message header.

The response must contain one of the following header information: Date, ETag, Server, Vary unless this header information has already been set in the cache.

The client should not resubmit this request without modification.

This status code indicates that the current request requires user authentication. The response must contain a WWW-Authenticate information header applicable to the requested resource to query user information.

The client can resubmit a request containing appropriate Authorization header information. If the current request already contains Authorization credentials, then a 401 response represents that the server authentication has rejected those credentials.

Unlike the 401 response, authentication cannot provide any help, and this request should not be resubmitted. If this is not a HEAD request, and the server wishes 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.

No information can tell the user whether this situation 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 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 response must return an Allow header information to indicate the list of request methods that the current resource can accept.

Since PUT and DELETE methods will perform write operations on resources on the server, 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.

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 any changes.

This code is only allowed to be used in such situations: users are considered to be able to resolve the conflict and will resubmit new requests.

Such a situation should be considered permanent. If possible, clients with link editing functionality should delete all references pointing to this address.

In this case, the server can close the connection to prevent the client from continuing to send this request.

The response may contain a Retry-After header, suggesting how long the user should wait before trying again.

The server encountered an unexpected situation that caused it to be unable to complete processing the request. Generally speaking, this problem occurs when there is an error in the server's program code.

When the server cannot recognize the request method and cannot support its request for any resource, this status code is appropriate.

502 errors usually cannot be fixed by the client, but need to be fixed by the intervening web server or proxy server.

Usually, this is just a temporary state. If the delay time can be predicted, then the response can include a Retry-After header to indicate this delay time. If this Retry-After information is not given, then the client should handle it in the same way as handling a 500 response.

Note: Some proxy servers return 400 or 500 errors when DNS queries time out.