Strong Random Password Generator
HTTP Status CodeMeaning of Status Code
100The client should continue sending the request. This interim 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 to send the remaining part of the request, or if the request has been completed, ignore this response. 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 to use a different protocol to complete the request through the Upgrade message header. After sending the last empty line of this response, the server will switch to the protocols defined in the Upgrade message header. Such measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a newer version of HTTP than the old version is more advantageous, or switching to a real-time and synchronous protocol to transmit resources that take advantage of such characteristics.
102A status code extended by WebDAV (RFC 2518), representing that processing will continue.
200 The request has succeeded, and the response body or response headers requested will be returned with this response.
201The request has been fulfilled, and a new resource has been created as a result of the request, and its URI has been returned with the Location header information. If the necessary resource cannot be established in a timely manner, '202 Accepted' should be returned.
202The server has accepted the request, but has not yet processed it. As it may be rejected, the final request may or may not be executed. In the case of asynchronous operations, there is no more convenient way than sending this status code. The purpose of a response with a 202 status code is to allow the server to accept requests from other processes (such as a batch operation that runs only once a day), without having to keep the client connected to the server until all batch operations are completed. A response that accepts processing and returns a 202 status code should include some information indicating the current state of processing in the returned entity, as well as a pointer to the ** or status prediction of the processing, so that users can estimate whether the operation has been completed.
203The server has successfully processed the request, but the returned entity header metadata is not a valid definitive set on the original server, but comes from a local or third-party copy. The current information may be a subset or superset of the original version. For example, metadata containing resources may lead to the original server knowing the superset of metadata. The use of this status code is not mandatory, and it is only appropriate when the response would return 200 OK without using this status code.
204The server has successfully processed the request, but there is no need to return any entity content, and it is hoped to return updated metadata. The response may return new or updated metadata in the form of entity headers. If these header information exists, it should correspond to the requested variables. If the client is a browser, then the user's browser should keep the page that sent the request, without any changes to the document view, even if the new or updated metadata should be applied to the document in the user's browser's active view according to the specification. 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 has successfully processed the request and did not return any content. However, unlike the 204 response, a response with this status code requires the requester to reset the document view. This response is mainly used to immediately reset the form after accepting user input, so that users can easily start another input. Like the 204 response, this response is also prohibited from containing any message body and ends with the first blank line after the message header.
206The server has successfully processed a partial GET request. HTTP download tools like FlashGet or Thunder are using this type of response to implement breakpoint resumption or to break down a large document into multiple download segments for simultaneous download. The request must include Range header information to indicate the range of content the client wants, and may include If-Range as a request condition. The response must include the following header fields: Content-Range to indicate the range of content returned in this response; If the Content-Type is multipart/byteranges for multi-part downloads, each multipart segment should include a Content-Range field to indicate the range of content for this segment. If the response contains Content-Length, then its value must match the actual byte size 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 their values may differ from the values corresponding to other responses with the same variable. If this response request used If-Range strong cache validation, then this response should not include any other entity headers; if this response's request used If-Range weak cache validation, then this response is prohibited from including any other entity headers; this avoids inconsistencies between the cached entity content and the updated entity header information. Otherwise, this response should include all the entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers cannot be precisely matched, 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 the 206 response.
207A status code extended by WebDAV (RFC 2518), representing that the subsequent message body will be an XML message, and may contain a series of ** response codes according to the number of previous sub-requests.
300The requested resource has a series of alternative choices, each with its own specific address and browser-driven negotiation information. Users or browsers can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity listing the characteristics and addresses of resources so that users or browsers can choose the most suitable redirection address. The format of this entity is determined by the format defined by Content-Type. Browsers may automatically make the most suitable choice based on the response format and the browser's own capabilities. Of course, the RFC 2616 specification does not stipulate how such automatic selection should be carried out. If the server itself has a preferred choice of feedback, it should indicate the URI of this feedback in Location; browsers may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable.
301The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the URIs returned in this response. If possible, clients with link editing capabilities should automatically modify the address of the requested to the address returned by 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 entity of the response should contain hyperlinks pointing to the new URI and a brief explanation. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless the user confirms, because the conditions of the request may change. Note: For some browsers using the HTTP/1. protocol, when they send a POST request and receive a 301 response, the subsequent redirection request will become a GET method.
302The requested resource is now temporarily responding to the request from a different URI. Since such redirection is 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 Location field of the response. Unless this is a HEAD request, the entity of the response should contain hyperlinks pointing to the new URI and a brief explanation. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless the user confirms, because the conditions of the request may change. Note: Although RFC 1945 and RFC The 2068 specification does not allow clients to change the request method when redirecting, but many existing browsers treat a 302 response as a 303 response and access the URI specified in the Location using the GET method, regardless of the original request method. The status codes 303 and 307 were added to clarify what kind of response the server expects from the client.
303The response corresponding to the current request can be found at another URI, and the client should access that resource using the GET method. The existence of this method is mainly to allow the output of POST requests activated by scripts to redirect to a new resource. This new URI is not an alternative reference to the original resource. Also, the 303 response is prohibited from being cached. Of course, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response should contain a hyperlink pointing to the new URI and a brief explanation. Note: Many browsers before the HTTP/1.1 version cannot 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 in exactly the way the specification requires the client to handle 303 responses.
304If the client sends a conditional GET request that is allowed, and the content of the document has not changed since the last visit or according to the request conditions, the server should return this status code. The 304 response is prohibited from including a message body, so it always ends with the first blank line after the message header. This response must include the following header information: Date, unless the server does not have a clock. If a server without a clock also follows these rules, then proxy servers and clients can add the Date field to the received response header themselves (as stipulated in RFC 2068), and the caching mechanism will work normally. ETag and/or Content-Location, if the same request should return a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from the values corresponding to other responses with the same variable. If this response request uses strong cache validation, then this response should not include other entity headers; otherwise (for example, a conditional GET request using weak cache validation), this response is prohibited from including other entity headers; this avoids inconsistencies between the cached entity content and the updated entity header information. If a 304 response indicates that a current entity is not cached, then the caching system must ignore this response and resend a request without restriction conditions. If a 304 response is received that requires updating a cached entry, then the caching system must update the entire entry to reflect the values of all fields that have been updated in the response.
305The requested resource must be accessed through the specified proxy. The Location field will provide the URI information of the specified proxy, and the recipient needs to resend a separate request through this proxy to access the corresponding resource. Only the original server can establish a 305 response. Note: RFC In the 2068 specification, it is not explicitly stated that the 305 response is for redirecting a single request, and it can only be established by the original server. Ignoring these restrictions may lead to serious security consequences.
306In the latest version of the specification, the 306 status code is no longer used.
307The requested resource is temporarily being responded to from a different URI. Since such redirection is 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 Location field of the response. Unless this is a HEAD request, the entity of the response should contain a hyperlink pointing to the new URI and a brief explanation. Because some browsers cannot recognize the 307 response, it is necessary to add the above information so that users can understand and make access requests to the new URI. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless the user confirms, because the conditions of the request may change.
4001. There is a semantic error, and the current request cannot be understood by the server. Unless modified, the client should not resubmit this request. 2. There is an error in the request parameters.
401The current request requires user authentication. This response must include a WWW-Authenticate header suitable for the requested resource to inquire about user information. The client can resubmit a request containing the appropriate Authorization header. If the current request already contains an Authorization certificate, then the 401 response means that the server has rejected those certificates. If the 401 response contains the same authentication inquiry as the previous response, and the browser has tried authentication at least once, then the browser should present the entity information contained in the response to the user, because this entity information may contain relevant diagnostic information. See RFC 2617.
402This status code is reserved for potential future needs.
403The server has understood the request but refuses to execute it. Unlike the 401 response, authentication does not help, and this request should not be resubmitted. If this is not a HEAD request, and the server wants to explain why the request cannot be executed, it should describe the reason for refusal in the entity. Of course, the server can also return a 404 response if it does not want to let the client get any information.
404Request failed, the resource requested was not found on the server. There is no information to 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 has been permanently unavailable due to some internal configuration issues, and there is no address to jump to. The 404 status code is widely used when the server does not want to reveal why the request was rejected or there is no other suitable response available.
405The request method specified in the request line cannot be used for the requested resource. This response must return an Allow header to indicate a list of request methods that the current resource can accept. Since PUT, DELETE ** performs write operations on the server's resources, most web servers do not support or do not allow the above request methods by default, and will return a 405 error for such requests.
406The content characteristics of the requested resource cannot meet the conditions in the request header, and therefore the response entity cannot be generated. Unless this is a HEAD request, the response should return an entity containing a list of entity characteristics and addresses that the user or browser can choose from. 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 standards for such automatic selection.
407Similar to the 401 response, 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.
408Request Timeout. The client did not produce a request within the time that the server was prepared to wait. The client may repeat this request without modifications at any later time.
409Conflict. The request could not be completed due to a conflict with the current state of the resource. This code only allows to be used under the circumstances where the user is considered capable of resolving the conflict, and will submit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts usually occur in the handling of PUT requests. For example, in an environment with version checking, a modification request for a specific resource submitted by a PUT submission with version information attached conflicts with a previous request (third party), then the server should return a 409 error, informing the user that the request cannot be completed. At this time, the response entity is likely to contain a comparison of the differences between the two conflicting versions, so that the user can resubmit a new version after merging.
410Gone. The requested resource is no longer available at the server and no forwarding address is known. This condition should be considered permanent. Clients with link editing capabilities should delete references to this address after obtaining user consent if possible. If the server does not know or cannot determine whether this condition is permanent, then the 404 status code should be used. Unless otherwise stated, this response is cacheable. The purpose of the 410 response is mainly to help webmasters maintain the website, notify users that the resource is no longer available, and the server owner wants all remote connections pointing to this resource to be deleted. This kind of event is very common in time-limited, value-added services. Similarly, the 410 response is also used to notify the client that the resources originally belonging to an individual on the current server site are no longer available. Of course, whether to mark all permanently unavailable resources as '410 Gone', and how long to keep this mark, depends entirely on the server owner.
411Length Required. The server refuses to accept the request without a defined 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.
412Precondition Failed. The server did not meet one or more of the preconditions given in the request's header fields when it was validating them. This status code allows the client to set preconditions in the metadata of the request (request header field data) when obtaining a resource, to avoid applying the request method to resources other than what they desire.
413Payload Too Large. The server refuses to process the current request because the size of the entity data submitted with the request exceeds the range that the server is 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 situation is temporary, the server should return a Retry-After response header to inform the client when to try again.
414URI Too Long. The length of the requested URI exceeds the length that the server can interpret, so the server refuses to provide service for this request. This is relatively rare and usually includes situations such as: form submissions that should have used the POST method turned into GET methods, resulting in a query string (Query String) that is too long. Redirection URI "black hole", for example, each redirection takes the old URI as part of the new URI, causing the URI to be too long after several redirections. The client is trying to exploit some security vulnerabilities in the server. Such servers use fixed-length buffers to read or operate on the request URI, and when the GET parameters exceed a certain value, it may cause a buffer overflow, resulting in arbitrary code execution [1]. Servers without such vulnerabilities should return a 414 status code.
415The entity submitted in the request is not supported by the server in the format for the resource being requested by the current method, thus the request is refused.
416If the request includes a Range request header, and none of the data ranges specified in the Range overlap with the current resource's available range, and there is no If-Range request header defined, then the server should return a 416 status code. If the Range uses a byte range, then this situation means that all the data ranges specified in the request have a starting byte position that exceeds the length of the current resource. The server should also include a Content-Range entity header when returning a 416 status code, to indicate the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type.
417The expectation given in the Expect request header cannot be met by the server, or the server is a proxy server, and it has clear evidence that the Expect content cannot be met at the next node in the current route.
421The number of connections from the current client's IP address to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client's address seen from the server (such as the user's ** or proxy server address). In this case, the calculation of the number of connections may involve more than one end user.
422The number of connections from the current client's IP address to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client's address seen from the server (such as the user's ** or proxy server address). In this case, the calculation of the number of connections may involve more than one end user.
422The request format is correct, but due to semantic errors, it cannot be responded to. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
424Due to an error in a previous request, the current request fails, such as PROPPATCH. (RFC 4918 WebDAV)
425Defined in the WebDav Advanced Collections draft, but does not appear in the "WebDAV Ordered Collection Protocol" (RFC 3658).
426The client should switch to TLS/1.0。 (RFC 2817)
449Extended by Microsoft, it means that the request should be retried after performing the appropriate action.
500The server encountered an unexpected condition that prevented it from fulfilling the request.
501The server does not support the functionality required to fulfill the request.
502As a gateway or proxy server, the server received an invalid response from the upstream server when attempting to fulfill the request.
503The server is currently unable to handle the request due to temporary maintenance or overload. This is a temporary state and will be restored after some time. If the delay time can be estimated, a Retry-After header can be included in the response to indicate this delay time. If no Retry-After information is given, the client should handle it in the same way as 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 reject the client's connection.
504As a gateway or proxy server, the server did not receive a timely response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or auxiliary server (such as DNS) when attempting to fulfill the request. Note: Some proxy servers may return a 400 or 500 error when a DNS query times out.
505The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or is unwilling to use the same version as the client. The response should include an entity that describes why the version is not supported and which protocols the server supports.
506Extended by the "Transparent Content Negotiation Protocol" (RFC 2295), it means that there is an internal configuration error on the server: the requested variant resource is configured to use itself in transparent content negotiation, and is therefore not a suitable focus in a negotiation process.
507The server cannot store the content required to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
509The server has reached the bandwidth limit. This is not an official status code, but it is still widely used.
510 The policy required to obtain the resource is not satisfied.（RFC 2774）
Your footprint:

Online Tools Navigation

Friendship link： Online Tool Network masters tool Calculation Assistant mathematical calculator ipsaya Random IP Strong Random Password Generator 2 to the power of what is 1/64 Globe Ask hello wordl Live Clock Numbers to Letters Pokemon Guide Snail Bob Red Light Green Light Game Excel Game Block Blast Unblocked Incredibox Sprunki Today Lucky Number Military Time Chart Chronological Age Calculator 12 Weeks From Today Weeks From Today Bottleneck Calculator Letters to Numbers