HTTP status code error list

If you send a request to your server to display a webpage on your website (for example, when a user accesses your webpage through a browser or crawls the webpage on googlebot, your server returns the HTTP statusCodeTo respond to this request.

This status code provides information about the request status and provides googlebot with information about your website and the requested webpage.

Some common status codes are as follows:

• 200-The server returns the webpage successfully.
• 404-The requested webpage does not exist.
• 503-The server is temporarily unavailable.

The following provides a complete list of HTTP status codes. Click the link to learn more. You can also visit the W3C page on the HTTP status code to learn more.

1xx (temporary response)
The status code that indicates a temporary response and requires the requester to perform the operation to continue.

Code	Description
100 (continue)	The requester shall continue to make the request. The server returns this code, which means that the server has received the first part of the request and is waiting to receive the remaining part.
101 (switching Protocol)	The requester has requested the server switching protocol, and the server has confirmed and is ready to switch.

2XX (successful)

The status code indicating that the server has successfully processed the request.

Code	Description
200 (successful)	The server has successfully processed the request. Generally, this indicates that the server provides the requested webpage. If your robots.txt file is in this status, this indicates that googlebot has successfully retrieved the file.
201 (created)	The request is successful and the server has created a new resource.
202 (accepted)	The server has accepted the request but has not processed it.
203 (unauthorized information)	The server has successfully processed the request, but returns information that may come from another source.
204 (NO content)	The server successfully processes the request but does not return any content.
205 (reset content)	The server successfully processes the request but does not return any content. Unlike the 204 response, this response requires the requester to reset the document view (for example, clear the form content to enter new content ).
206 (partial content)	The server successfully processes some GET requests.

3xx (redirected) 
To complete the request, you must perform further operations. These status codes are usually always redirected. Google recommends that you use fewer than five redirection entries for each request. You can use the website administrator tool to check if googlebot encounters any problems when crawling your redirected webpage.DiagnosisThe capture error page below lists the URLs that cannot be crawled by googlebot due to a redirection error.

Code	Description
300 (multiple options)	The server can perform multiple operations based on the request. The server selects an operation based on the user agent or provides an operation list for the user agent to select.
301 (permanent movement)	The requested webpage has been permanently moved to a new location. When the server returns this response (as a response to a get or head request), it automatically redirects the requester to a new location. You should use this code to notify googlebot that a webpage or website has been permanently moved to a new location.
302 (temporary movement)	The server is currently responding to requests from different web pages, but the requester should continue to use the original location for future requests. Similar to code 301 In response to get and head requests, this code automatically redirects the requester to different locations. However, because googlebot continues to capture the original location and indexed it, you should not use this code to notify googlebot that a page or website has been moved.
303 (view other locations)	The server returns this code when the requester must perform separate GET requests at different locations to retrieve the response. For all requests except HEAD requests, the server automatically redirects to other locations.
304 (not modified)	The requested webpage has not been modified since the last request. When the server returns this response, no webpage content is returned. If the web page has not been changed since the last request, you should Configure the server to return this response (known as the IF-modified-since HTTP header ). The server can tell googlebot that the webpage has not been changed since the previous capture, thus saving bandwidth and overhead. .
305 (use proxy)	The requester can only use a proxy to access the requested webpage. If the server returns this response, the server also specifies the proxy that the requester should use.
307 (temporary redirection)	The server is currently responding to requests from different web pages, but the requester should continue to use the original location for future requests. Similar to code 301 In response to get and head requests, this code automatically redirects the requester to different locations. However, because googlebot continues to capture the original location and indexed it, you should not use this code to notify googlebot that a page or website has been moved.

4xx (request error) 
These status codes indicate that the request may fail and the server may be unable to process the request.

Code	Description
400 (incorrect request)	The server does not understand the request syntax.
401 (unauthorized)	The request requires authentication. After logon, the server may return this response to the page.
403 (Forbidden)	The server rejects the request. If this status code is displayed when googlebot tries to capture a valid webpage on your website (you can go to the Google website administrator toolDiagnosisUnderNetwork captureThis status code is displayed on the page). This may be because your server or host rejects googlebot access to it.
404 (not found)	The server cannot find the requested webpage. For example, if the request is for a webpage that does not exist on the server, the server usually returns this code. If the robots.txt file does not exist on your website and you find this status on the robots.txt page of the Google website administrator tool "Diagnostics" tab, this is the correct status. However, if you have a robots.txt file and find this status again, it indicates that your robots.txt file may be named incorrectly or located in the wrong location. (The file should be on a top-level domain name and be named robots.txt ). If you find this status (on the HTTP Error page of the "diagnosis" tab) on the URL that googlebot is trying to crawl, this indicates that googlebot may be tracking invalid links in another webpage (old links or incorrect links ).
405 (method disabled)	Disable the method specified in the request.
406 (not accepted)	You cannot use the Content features of the request to respond to the requested webpage.
407 (proxy authorization required)	This status code is similar to 401 (unauthorized), but specifies that the requester should use a proxy for authorization. If the server returns this response, the server also specifies the proxy that the requester should use.
408 (request timeout)	The server timed out while waiting for the request.
409 (conflict)	A conflict occurs when the server completes the request. The server must contain information about conflicts in the response. The server may return this code when responding to a put request that conflicts with the previous request, and provides a list of differences between the two requests.
410 (Deleted)	If the requested resource has been permanently deleted, the server returns this response. This code is similar to the 404 (not found) code, but sometimes it may replace the 404 code when the resource exists but does not exist now. If the resource has been permanently deleted, you should use code 301 to specify a new location for the resource.
411 (valid length required)	The server will not accept requests that contain invalid Content Length header fields.
412 (not meeting the prerequisites)	The server does not meet one of the prerequisites set by the requester in the request.
413 (the Request Entity is too large)	The server cannot process the request because the request entity is too large and exceeds the server's processing capability.
414 (the requested URI is too long)	The request URI (usually the URL) is too long and cannot be processed by the server.
415 (unsupported media type)	The request format is not supported by the request page.
416 (the request range does not meet the requirements)	If the request is for an invalid webpage range, the server returns this status code.
417 (expectations not met)	The server does not meet the "expected" request header field requirements.

5xx (server error)
These status codes indicate that an internal error occurs when the server attempts to process the request. These errors may be server errors rather than request errors.

Code	Description
500 (internal server error)	The request cannot be completed due to a server error.
501 (not implemented)	The server does not have the function to complete the request. For example, if the server cannot identify the request method, the server may return this code.
502 (incorrect gateway)	The gateway or proxy server receives an invalid response from the upstream server.
503 (Service unavailable)	Currently, servers cannot be used (due to overload or downtime maintenance ). This is usually a temporary state.
504 (gateway timeout)	As a gateway or proxy, the server does not receive requests from the upstream server in a timely manner.
505 (unsupported HTTP Version)	The server does not support the HTTP protocol version used in the request.

 

 

In general, the first or two digits of the Error Code indicate the type of the error. The first digit is 1, indicating general information, and the first digit is 2, indicating successful information, if the request is successfully executed, 3 indicates a redirection error. For example, the target to be accessed has been transferred to another location. 4 indicates a client error, for example, if the user identity is invalid or the request syntax is incorrect, the first value is 5, indicating a server error. For example, if the proxy server fails or the user's request is not supported, the first two values are 10, indicating a connection error, if the connection is disconnected or times out, if the first two are 11, it indicates a host error. If the host cannot be found, if the first two are 12, it indicates a proxy error, such as a recursive proxy.
A temporary response, that is, a message response, indicates that the other server is processing the request and has not yet decided on the final response. If it takes more than ms for the server to process the request to generate an end response, it should send a 1xx response.
Note that 1xx responses are not reliably transmitted. They will not cause the client to send an ACK response. A temporary (1xx) response can contain a message body and a session description.
1.1 100 trying
This response indicates that the server of the next node has received the request and has not executed the specific action of the request (for example, when the database is being opened ). This response, like other temporary responses, has been planted with UAC to resend INVITE requests. The 100 (trying) response is different from other temporary responses. Here, it will never be forwarded to the upstream stream by a stateful proxy.
1.2 180 ringing
UA receives the invite request and tries to prompt the user. This response should generate a local response.
1.3 818 call is being forwarded (Call forwarded)
The server can use this response code to indicate that the call is being forwarded to another destination set.
1.4 182 queued
When the caller is temporarily unable to receive the call, and the server decides to wait in queue for the call, rather than rejecting the call, the server should send this response. When the called party resumes receiving the call, it will return an appropriate final response. For this call status, there can be a phrase indicating the reason, such as: "5 callqueued; Expected waiting time is 15minutes ". The server can provide several 182 (queued) Responses to inform the caller of the queue (for example, the queue is in front of the queue ).
1.5 183 session progress
The 183 (session progress) response is used to indicate the progress of the conversation. Reason-phrase (a sentence that expresses the reason), header domain, or message body can be used to display more information about the call progress.
2. Successful message 2XX
This response indicates that the request is successful.
2.1 200 OK
The request has been processed successfully. This information depends on the response of requests of different methods.
3 forwarding request 3xx
The 3xx series of responses are used to indicate the user's new location information or to forward additional service locations to meet the call requirements.
3.1 300 multiple choices
There are multiple choices for the requested address. Each choice has its own address. The user or (UA) can select an appropriate communication terminal and forward the request to this address.
A response can contain a Resource feature that is allowed in the accept request header domain at each location, so that the user or ua can select the most appropriate address to forward the request. The message body that does not have this response defines the MIME type.
These addresses should also be listed in the contact header field (section 20.10 ). Unlike HTTP, a SIP response can contain multiple contact header domains or a contact header domain with an address list. UA can use the Contact Header domain for automatic forwarding or ask the user to confirm the forwarding. However, this specification does not define the automatic forwarding standard.
If the called party can be found at multiple addresses and the server cannot or is unwilling to forward the request, this response can be used to send the request to the caller.
3.2 301 moved permently
When the user cannot be found at the address specified by request-Uri, the requested client should try again using the new address specified by the Contact Header domain (20.10. The requester should use this new value to update the local directory, address book, and user address cache, and send it to these listed addresses in subsequent requests.
3.3 302 moved temporarily
The requester should re-send the request to the new address (20.10) specified in the contact header domain ). The request-Uri of the new request should use the value specified by the contact header field in the response.
The expires (section 20.19) in the response or the expires parameter in the contact header field defines the lifecycle of the contact Uri. UA or proxy caches the URI in this lifecycle. If there is no strict validity period, this address is only valid this time and cannot be saved in future transactions.
If the value of the contact header field in the cache fails, the request-Uri of the forwarded request should be tried again. A temporary URI can expire faster than the timeout time and have a new temporary Uri.
3.4 305 use proxy
The requested resource must be accessed through the proxy specified in the contact header. The contact header specifies the URI of a proxy. The object receiving this response should resend this single request through this proxy. 305 (useproxy) must be generated by UAS.
3.5 380 alternative service
The call fails, but you can try another service. In addition, the Service is defined in the Response Message Body. The message body format is not defined here and may be defined in future specifications.
4. Request failed 4xx
The 4xx response defines the failure of the Request returned by a specific server. The client should not retry the same request without changing the request. (For example, add appropriate authentication information ). However, the same request may be successfully sent to different servers.
4.1 400 bad request
Syntax Error in the request. Reason-phrase should mark this detailed syntax error, such as "Missing Call-ID header field ".
4.2 401 unauthorized
User authentication is required for the request. This response is generated by the UAS and registration server. When 407 (proxy authentication required) is generated by the proxy server.
4.3 402 payment required
Reserved/used later
4.4 403 Forbidden
The server supports this request, but the request is rejected. Adding verification information is unnecessary and requests should not be retried.
4.5 404 not found
The server returns the final information: the user does not exist in the domain specified by request-Uri. This response is also generated when the domain of request-Uri does not match the domain that receives the request.
4.6 405 method not allowed
The server supports the method in request-line, but the method cannot be applied to the address in the request-Uri.
The response must include an allow header field that contains the list of methods allowed by the specified address.
4.7 not acceptable
The requested resource will only generate an error outside the accept header of the request and the content cannot be received.
4.8 407 proxy authentication required
This return code is similar to 401 (unauthorized), but it indicates that the client must first pass authentication on the proxy. For more information about access to the authentication service, see sections 26 and 22.3.
This return code is used by the application Program Access a communication gateway (such as a telephone gateway), which is rarely used by the called party for authentication.
4.9 408 request timeout
Within a period of time, the server cannot generate an ending response, for example, if it cannot determine the user's location in a timely manner. The client can try again later without changing the request content.
4.10 410 gone
The requested resource does not exist on this server and you do not know where to forward the request. This problem will be permanent. If the server does not know, or is not easy to detect, whether the resource disappears temporarily or permanently, a 404 (not found) error should be returned ).
4.11 413 the Request Entity is too large.
The server rejects the request because the request entity exceeds the size that the server wants or can process. The server should close the connection to prevent the client from sending this request again.
If this is temporary, the server should contain a retry-after header to indicate that this is a temporary fault and the client can try again later.
4.12 414 request-URI Too Long
The server rejects this request because the request-Uri exceeds the length that the server can process.
4.13 415 unsupported media type
The server rejects the request because the request message body format is not supported by the server. The server must return an ACCEPT, accpet-encoding, or accept-Language Header domain list based on the fault type of the content. UAC processes this response according to the method defined in section 8.1.3.5.
4.14 416 unsupported URI Scheme
The server terminates the request because it does not support the URI scheme in request-Uri. For the client to process this response, see 8.1.3.5.
4.15 bad Extension
The server does not know the Protocol extensions specified by the proxy-require (20.29) or require (20.32) header in the request. The server must list unsupported extensions in the unsupported header field. For how UAC handles this response, see 8.1.3.5
4.16 421 extension required
UAS requires a specific extension to process this request, but this extension is not listed in the supported header domain of the request. The response with this response code must contain a require header domain to list the required extensions.
UAS should not use this response unless it really cannot provide valid services to the client. Conversely, if the required extensions are not listed in the support header domain, the server should handle them based on the benchmark sip-compatible method and client-supported extensions.
4.17 423 interval too brief
The server rejects the request because the resource refresh time (or validity period) set in the request is too short. This response can be used to register servers to reject registration requests with too short contact header domain validity periods. The usage of this response and the related min-expires header fields are described and described in sections 10.2.8, 10.3, and 20.23.
4.18 480 temporarily unavailable
The request has successfully arrived at the terminal system of the called party, but the called party is currently unavailable (for example, if you have not logged on, or logged on, but cannot communicate, or you have a "do not disturb" flag ). The response should be retried-after with a suitable resend time. This user may also be valid elsewhere (not known on the server ). Reason-phrase (reason short) should prompt more detailed reasons why the called party is temporarily unavailable. This value should be set by UA. The 486 (busy here) status code can be used to more accurately indicate the specific cause of the Request failure.
This status code can also be returned by the forwarding service or the proxy server because they find that the user specified by request-Uri exists, but there is no suitable address for the user to forward.
4.19 481 call/transaction does not exist
This status indicates that the UAS receives the request but does not match the existing dialog or transaction.
4.20 482 loop Detected
The server detects a loop (16.3/4)
4.21 483 too average hops
The server receives a request containing the max-forwards (20.22) header field 0.
4.22 484 address incomplete
When the server receives a request, its request-Uri is incomplete. Additional information should be included in the reason phrase. This status code can overlap with dialing. The client does not know the length of the dialing string when it overlaps with the dialing. It sends a string with an increased length and prompts the user to enter more strings until the 484 (address incomplete) response does not appear.
4.23 485 ambiguous
The request-Uri is not clear. A Possible Clear address list can be contained in the contact header. This prompt list may cause damage to users or organizations in terms of security and privacy. You must be able to determine whether to replace this response with 404 (notfound) by configuration, or disable the use of possible selection lists for ambiguous addresses.
An example of a response to a request with request-Uri:
SIP: lee@example.com:
Sip/2.0 485 ambiguous
Contact: Carol Lee
Contact: Ping Lee
Contact: Lee M. Foote
Some email and voice mail systems provide this function. This status code is different from the 3xx status code: for 300, it assumes that the same person or service has different address options. Therefore, for 3xx, automatic system selection or continuous search is effective, but for 485 (ambiguous) responses, user intervention is required.
4.24 486 busy here
When the caller successfully contacts the caller's terminal system, but the caller cannot answer the call on the terminal system, then the response should be sent back to the caller at a more appropriate time in the retry-after header domain for retry. This user may be valid elsewhere, such as the phone and email system. If we know that no other terminal system can answer this call, we should return a status code 600 (busy everywhere ).
4.25 487 request terminated
The request is terminated by bye or cancel. This response will never reply to the cancel request itself.
4.26 488 not acceptable here
This response has the same meaning as 606 (not acceptable), but it is only applied to the specific resource specified by request-Uri and may be accepted elsewhere.
A Message Body Containing the media compatibility description can appear in the response and be normalized Based on the accept header field in the invite request (if there is no accept header field, it is application/SDP ). This response is like the message body that responds to the options request 200 (OK.
4.27 491 request pending
In the same dialog, the request received by UAS has a dependent request being processed. 14.2 describes how this situation should be solved.
4.28 493 undecipherable
UAS receives a request that contains an encrypted mime and does not know or provide a suitable decryption key. This response can contain a single packet body, which contains the appropriate public key used to encrypt the packet body in UAS communication. Details are described in section 23.2.
5 Server failure 5xx
The 5xx response is a failure response provided when the server itself fails.
5.1 500 server internal error
The server encounters an unknown situation and cannot continue to process the request. The client can display specific error conditions and try the request again after several seconds.
If this is temporary, the server should try the request again after the retry-after header domain marks how many seconds the client has passed.
5.2 501 not implemented
The server does not implement related request functions. When UAS does not know the Request Method and does not support this method for every user, it should return this response. (Proxy forwards the request without considering the request method ).
Note that 405 (method not allowed) is because the server implements this request method, but this request method is not supported in a specific request.
5.3 502 Bad Gateway
If the server exists as a gateway or proxy, an invalid response is received from the downstream server (the request corresponding to this response is forwarded to the downstream server to complete the request ).
5.4 503 service unavailable
The server is temporarily unavailable due to temporary overload or server management. This server can add a retry-after in the response to allow the client to retry the request. If no retry-after clause is specified, the client must process the request as if it received a 500 (server internal error) response.
When the client (proxy or UAC) receives the 503 (Service unavailable) request, it should try to forward the request to another server for processing. In addition, other requests should not be forwarded to this server within the time specified in the retry-after header domain.
As an alternative to 503 (Service unavaliable), the server can reject the connection or throw the request.
5.5 504 server time-out
The server does not receive a prompt response on an external server. This external server is used by this server to access and process this request. If the Expires header field in the request received from the upstream server times out, a 408 (request timeout) error should be returned.
5.6 505 version not supported
The server does not support the corresponding sip version. The server cannot process requests with the same major version number provided by the client, which leads to such an error.
5.7 message to large
The server cannot process the request because the message length exceeds the processing length.
6 Global failures 6xx
The 6xx response indicates that the server provides a final message to a specific user, not only when the request-Uri instance has final information.
6.1 600 busy everywhere
The caller is successfully contacted by the caller's terminal system. However, the caller is busy and does not intend to answer the call. You can add a retry-after header to explicitly tell the caller how long it will take to continue the call. If the called party does not want to prompt the reason for rejection, the called party should use decline ). This response can be used only when the terminal system knows that no terminal node (such as the voice mailbox system) can access this user. Otherwise, a 486 (busy here) response should be returned.
6.2 603 decline
When the caller's device is successfully accessed, the user explicitly does not want to respond. You can add a retry-after header to explicitly tell the caller how long it will take to continue the call. Only when the terminal knows that no other terminal device can respond to this call can this response be provided.
6.3 604 does not exists anywhere
The server verifies the user information of the request-URI in the request and does not exist anywhere.
6.4 606 not acceptable
When a UA is successfully connected, some parts of the session description, such as the requested media, bandwidth, or address type, are not received.
The 606 (notacceptable) response means that the user wants to communicate, but cannot fully support the Session Description. 606 (not acceptable) a response can contain a reason list in the warning header to explain why the session description is not supported. The warning cause code is listed in section 20.43.
In the response, a message body containing the media compatibility description can appear. The message body format is normalized according to the format specified by the accept header field in the invite request (if there is no accept header field, it is application/SDP), just like the message in the 200 (OK) Response to options.
We hope that media negotiation is not frequently required. When a new user is invited to join an existing session, this media negotiation may not be required. This depends on whether the invited initiator needs to process 606 (not acceptable.
This response can be sent only when the client knows that no other terminal can process this request.