Http Status Code

If a request is made to your server to display a webpage on your site (for example, when a user accesses your page through a browser or when Googlebot crawls the page), your server returns an HTTP status code in response to the request.

This status code provides information about the status of the request and provides Googlebot with information about your site and the pages that you requested.

Some of the common status codes are:

• $-Server successfully returned to Web page
• 404 -The requested page does not exist
• 503 -The server is temporarily unavailable

The following provides a complete list of HTTP status codes. Click on the link to learn more. You can also access the information about the HTTP status code in the pages for details.

1XX (Temporary response)
A status code that represents a temporary response and requires the requestor to perform an action before continuing.

Code	Description
100 (Continue)	The requestor shall continue to make the request. The return of this code by the server means that the server has received the first part of the request and is now waiting to receive the remainder.
101 (Switching protocol)	The requestor has asked the server to switch protocols, and the server has confirmed and is ready to switch.

2XX (Success)

The status code used to indicate that the server has successfully processed the request.

Code	Description
200 (success)	The server has successfully processed the request. Typically, this indicates that the server provided the requested Web page. If your robots.txt file is displayed for this status, this means that Googlebot has successfully retrieved the file.
201 (created)	The request was successful and the server has created a new resource.
202 (accepted)	The server has accepted the request, but it has not been processed.
203 (non-authorised information)	The server successfully processed the request, but returned information that might have come from another source.
204 (no content)	The server successfully processed the request, but did not return any content.
205 (Reset content)	The server successfully processed the request, but did not return any content. Unlike the 204 response, this response requires the requestor to reset the document view (for example, to clear the form contents to enter new content).
206 (partial content)	The server successfully processed a partial GET request.

3xx (redirected)
To complete the request, you need to proceed further. Typically, these status codes are always redirected. Google recommends that you use less than 5 redirects per request. You can use the Webmaster tools to see if Googlebot is having problems crawling your redirected pages. The crawl error page under diagnostics lists the URLs that Googlebot cannot crawl due to redirection errors.

Code	Description
300 (multiple options)	The server can perform a variety of actions depending on the request. The server can select an action based on the requestor (user agent) or provide a list of actions for the requestor to select.
301 (Permanent movement)	The requested page has been permanently moved to a new location. When the server returns this response (as a response to a GET or HEAD request), the requestor is automatically forwarded to the new location. You should use this code to notify Googlebot that a Web page or Web site has been permanently moved to a new location.
302 (Temporary Move)	The server is currently responding to requests from Web pages in different locations, but the requestor should continue to use the original location for future requests. This code, like the 301 code that responds to the GET and HEAD requests, automatically transfers the requestor to a different location. However, since Googlebot will continue to crawl the original location and index it, you should not use this code to notify Googlebot that a page or site has been moved.
303 (See other locations)	The server returns this code when the requester should make a separate GET request for a different location to retrieve the response. For all requests except the HEAD request, the server automatically goes to a different location.
304 (not modified)	The requested webpage has not been modified since the last request. When the server returns this response, the Web page content is not returned. If the page has not changed since the requestor last requested it, you should configure the server to return this response (known as the If-modified-since HTTP header). Because the server can tell Googlebot that the page has not changed since the last crawl, it saves bandwidth and overhead 。
305 (use proxy)	The requestor can only use the proxy to access the requested Web page. If the server returns this response, the server also indicates which proxy the requestor should use.
307 (Temporary redirect)	The server is currently responding to requests from Web pages in different locations, but the requestor should continue to use the original location for future requests. This code, like the 301 code that responds to the GET and HEAD requests, automatically transfers the requestor to a different location. However, since Googlebot will continue to crawl the original location and index it, you should not use this code to notify Googlebot that a page or site has been moved.

4xx (Request error)
These status codes indicate that the request may have failed and that the server has been prevented from processing the request.

Code	Description
400 (Bad Request)	The server does not understand the syntax of the request.
401 (not authorized)	Requests for authentication are requested. After logging in, the server may return this response to the page.
403 (Forbidden)	The server rejected the request. If this status code appears when Googlebot tries to crawl a valid webpage on your site (you can see this status code on the Web crawl page in the Google Webmaster Tools Diagnostics ), then this could be your server or host rejecting Googlebot access to it.
404 (Not Found)	The server could not find the requested Web page. For example, if the request is for a webpage that does not exist on the server, the server typically returns this code. If you do not have a robots.txt file on your site and you find this status on the robots.txt page of the Google Webmaster Tools Diagnostics tab, this is the correct state. However, if you have a robots.txt file and you find this status, this means that your robots.txt file may be named incorrectly or in the wrong location. (the file should be located on the top-level domain name and should be named Robots.txt). If you find this status on the URL Googlebot trying to crawl (on the HTTP error page of the Diagnostics tab), this means that Googlebot may be tracking an invalid link (old link or incorrect input link) on another page.
405 (method Disabled)	Disables the method specified in the request.
406 (not accepted)	The requested content attribute cannot be used in response to the requested Web page.
407 (requires proxy authorization)	This status code is similar to 401 (unauthorized), but specifies that the requestor should use the proxy for authorization. If the server returns this response, the server also indicates which proxy the requestor should use.
408 (Request timed out)	The server timed out while waiting for the request.
409 (conflict)	The server encountered a conflict while completing the request. The server must contain information about the conflicts that occurred in the response. The server may return this code in response to a PUT request that conflicts with the previous request, and will provide a list of differences for 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 replaces the 404 code in cases where resources have previously existed but are no longer present. If the resource has been permanently deleted, you should use 301 code to specify a new location for the resource.
411 (valid length required)	The server does not accept requests that contain invalid content-Length header fields.
412 (precondition not met)	The server did not meet one of the prerequisites set by the requestor in the request.
413 (Request entity too Large)	The server was unable to process the request because the request entity was too large to exceed the server's processing power.
414 (The requested URI is too long)	The requested URI (usually the URL) is too long for the server to process.
415 (Unsupported media type)	The requested format is not supported by the requested page.
416 (Request scope does not meet the requirements)	If the request is made against an invalid range of pages, the server returns this status code.
417 (expectations not met)	The server does not meet the requirements for the expected Request header field.

5XX (server error)
These status codes indicate that an internal error occurred while the server was trying to process the request. These errors may be the error of the server itself, not the request.

Code	Description
500 (server internal error)	The server encountered an error and could not complete the request.
501 (not yet implemented)	The server does not have the capability to complete the request. For example, the server may return this code when the server does not recognize the request method.
502 (Wrong Gateway)	The server received an invalid response from the upstream server as a gateway or proxy.
503 (service not available)	The server cannot be used at this time (due to overloading or downtime maintenance). Usually, this is just a temporary state.
504 (Gateway Timeout)	The server acts as a gateway or proxy and does not receive requests from the upstream server in a timely manner.
505 (HTTP version not supported)	The HTTP protocol version used in the request is not supported by the server.

In general, the first or first two digits of the error message code represent the wrong type, where the first digit is 1 for general information, and the first bit is 2 for successful information, such as if the request is executed successfully, the first bit is 3 for the redirect error, such as the target to be accessed has been moved to another location, The first 4 indicates a client error, such as the user's identity is not valid or the requested syntax is incorrect, the first 5 indicates a service side error, such as a proxy server failure or does not support the user's request, the first two bits of 10 indicates a connection error, such as the connection is disconnected or timed out, the first two bits 11 is the host error, For example, the host is not found, the first two bits of 12 are proxy errors, such as recursive proxy, etc.
A temporary response, which is the nature of the message, is a sign that the other server is processing the request and has not yet decided on the final answer. It should send a 1xx response when the server is processing a request that takes more than 200ms to produce an end-of-answer.
Note that the 1XX response is not transmitted reliably. They do not cause the client to deliver an ACK response. The temporary (1xx) answer can contain the message body, which contains the session description.
1.1 Trying
The answer indicates that the server of the next node has received the request and has not performed a specific action on the request (for example, when the database is being opened). This response, like any other temporary response, planted the UAC to resend the invite request. The Trying response differs from the other ad hoc response, where it is never forwarded to the upstream stream by a stateful proxy.
1.2 Ringing
UA receives the invite request and attempts to prompt the user. This response should be born with a local ring back.
1.3 818 Call is Being forwarded (calls forwarded)
The server can use this answer code to indicate that a call is being forwarded to another destination collection.
1.4 182 Queued
This response should be issued when the caller is temporarily unable to receive the call, and the server decides to queue the call instead of rejecting the call. When the called party resumes receiving the call, he returns the appropriate termination answer. For this call state, there can be a phrase that represents the reason, such as: "5 calls queued;expected waiting time is 15minutes". The server can give several 182 (Queued) answers that tell callers to queue up (for example, queued up, and so on).
1.5 183 Session Progress
183 (Session Progress) answers the progress information used to prompt the dialog. Reason-phrase (the sentence that expresses the reason), the Head field, or the message body can be used to prompt for more information about the progress of the call.
2 Success Information 2xx
This response indicates that the request was successful.
2.1 OK
The request has been processed successfully. This information depends on the response of the request of the different methods.
3 Forwarding Request 3XX
The answer to the 3XX series is the additional service location that is used to prompt the user for new location information, or to be forwarded to meet the call.
3.1 Multiple Choices
The requested address has multiple choices, each with its own address, the user or (UA) can select the appropriate communication terminal, and forward the request to this address.
An answer can include a resource attribute that is allowed in the Accept request header domain for each location so that the user or UA can select the most appropriate address to forward the request. The MIME type is not defined for the message body without this response.
These address selections should also be listed in the Contact Header field (section 20.10). Unlike the Http,sip answer, you can include multiple contact header fields or a Contact header field that has an address list. UA can use the Contact header field to automatically forward or ask the user to confirm the forwarding. However, this specification does not define the standard for automatic forwarding.
If the called party can be found at more than one address and the server cannot or is unwilling to forward the request, it can be used to give the caller the answer.
3.2 301 Moved permently
When the user cannot be found at the address specified by Request-uri, the requesting client should retry with the new address indicated by the Contact header field (20.10). The requestor should use this new value to update the local directory, address Book, and user address cache, and in subsequent requests, send to this/these listed addresses.
3.3 302 Moved temporarily
The requesting party should resend the request to the new address (20.10) as indicated in the Contact header field. The Request-uri of the new request should use the value indicated by the Contact header field of this reply.
The lifetime of this contact URI is defined in the Expires (section 20.19) or the expires parameter of the Contacts Header field in the answer. The UA or proxy caches the URI for this lifetime. If there is no strict effective, then this address is only valid this time, and cannot be saved in future transactions.
If the value of the Contact header field of the cache fails, then the Request-uri of the forwarded request should try again. The temporary URI can be invalidated faster than the timeout and can have a new temporary URI.
3.4 305 Use Proxy
The requested resource must be accessed through a proxy indicated in the Contact header field. The Contact header field specifies the URI of a proxy. The object that receives the reply should resend the individual request through this proxy. 305 (UseProxy) must be produced by UAS.
3.5 380 Alternative Service
The call is not working, but you can try another service. Additional services are defined in the message body of the reply. The format of the message body is not defined here and may be defined in a later specification.
4 Request failed 4xx
The 4xx answer defines a scenario in which a request for a particular server response failed. The client should not retry the same request without changing the request. (for example, increase the appropriate authentication information). However, the same request may be successful if it is given to a different server.
4.1 Bad Request
The syntax error in the request. Reason-phrase should flag this detailed syntax error, such as "Missing Call-id header Field".
4.2 401 Unauthorized
The request requires user authentication. This response is generated by UAS and the registered server, when 407 (proxy authentication Required) is the proxy server.
4.3 402 Payment Required
Reserved/later use
4.4 403 Forbidden
The service side supports this request, but refuses to execute the request. It is not necessary to increase the authentication information, and the request should not be retried.
4.5 404 Not Found
The server returns the final message: The user does not exist on the domain specified by the Request-uri. This response is also generated when Request-uri domain does not match the domain that received the request.
4.6 405 Method not allowed
The server supports methods in Request-line, but it is not allowed to apply this method to addresses in this request-uri.
The answer must include an Allow header field that contains a list of methods allowed for the specified address.
4.7 Not acceptable
The resource in the request only causes an error that the content cannot receive in the request outside of the accept header.
4.8 407 Proxy Authentication Required
This return code and 401 (unauthorized) are class four, but the client should first pass the authentication on the proxy. For SIP authentication access, see sections 26 and 22.3.
This return code is used for application access to the communication gateway (for example, telephone gateways) and is seldom used for authentication by the called party.
4.9 408 Request Timeout
During a period of time, the server cannot produce an end response, for example, if it cannot determine the user's location in a timely manner. The client can then retry the request without changing the content of the request at a later time.
4.10 410 Gone
The requested resource does not already exist on this server and does not know where to forward the request. This problem will be permanent. If the server does not know, or is not easily detected, whether the resource disappears temporarily or permanently, then a 404 (not Found) should be returned.
4.11 413 Request entity is too large.
The server refused to process the request because the entity of the request exceeded the size that the server wanted or could handle. This server should close the connection to prevent the client from re-sending the request.
If the situation is temporary, then the server should include a Retry-after header field to indicate that this is a temporary failure, and the client can try again over time.
4.12 414 Request-uri Too Long
The server rejects this request because Request-uri exceeds the length that the server can handle.
4.13 415 Unsupported Media Type
The server is not supported due to the format of the requested message body, so it refuses to process this request. This server must return a accept,accpet-encoding, or accept-language header domain list, based on the type of failure of the content. UAC handles this response based on the method defined in section 8.1.3.5.
4.14 416 Unsupported URI Scheme
The server terminated processing this request because it does not support the URI scheme in Request-uri. The client handles this reply reference 8.1.3.5.
4.15 Bad Extension
The server does not know the protocol extension indicated in Proxy-require (20.29) or Require (20.32) header fields in the request. The server must list the unsupported extensions in the unsupported header domain. UAC handles this response see 8.1.3.5
4.16 421Extension Required
UAS requires a specific extension to handle this request, but the extension is not listed in the requested Supported header field. An answer with this answer code must contain an require header field that lists the required extensions.
UAS should not use this response unless it really does not provide a valid service to the client. Conversely, if the required extensions are not listed in the support header domain, the server should be processed based on the baseline SIP-compliant methods and the extensions supported by the client.
4.17 423 Interval Too Brief
The server rejected the request because the resource refresh time (or validity time) set in the request was too short. This response can be used to register the server to reject registration requests that have a short validity period for the contact header domain. The usage of this answer and the associated Min-expires header fields are described and explained in the 10.2.8,10.3,20.23 section.
4.18 480 Temporarily unavailable
The request successfully arrives at the called Party's terminal system, but the called Party is currently unavailable (for example, no login, or login but the status is not able to communicate, or there is a "do Not Disturb" tag). The answer should mark a suitable retry-after in the time of the re-send. This user is also likely to be valid elsewhere (not known in this server). Reason-phrase (reason) should be prompted for more detailed reasons why the called party is temporarily unavailable. This value should be set by UA. The Status Code 486 (Busy here) can be used to more precisely represent the specific cause of this request failure.
This status code can also be returned by the forwarding service or proxy server, as they find that the Request-uri specified user exists, but there is no appropriate current forwarding address for the user.
4.19 481 call/transaction Does not Exist
This state indicates that the UAS received the request but did not match the existing conversation or transaction.
4.20 482 Loop Detected
A loop was detected by the server (16.3/4)
4.21 483 Too Many Hops
The server received a request containing the Max-forwards (20.22) header domain is 0
4.22 484 Address Incomplete
The server received a request and its request-uri is incomplete. There should be an additional information description in the reason phrase. This status code can overlap with dial-up. In and dial-up overlaps, the client does not know the length of the dial string. It sends a string that increments the length and prompts the user to enter more strings until the 484 (Address incomplete) answer appears.
4.23 485 ambiguous
The Request-uri is not clear. The answer can include a possible explicit address list in the Contact header field. This list of hints is a compromise for users or organizations in terms of security and privacy. It must be possible for the configuration to decide whether to replace this answer with 404 (NotFound), or to disallow the use of a possible selection list for ambiguous addresses.
An example of a response to a request with Request-uri:
SIP: [Email protected]:
sip/2.0 485 ambiguous
Contact:carol Lee
Contact:ping Lee
Contact:lee M.foote
Part of the email and voice mail system provides this functionality. This status code differs from the 3XX status code: For 300来, it is assumed that the same person or service has different address choices. Therefore, for 3xx, automatic selection of the system or continuous search is effective, but for 485 (ambiguous) response, must be user intervention.
4.24 486 Busy here
When the called Party's terminal system is successfully contacted, but the called party is currently unable to answer the call on the terminal system, the answer should be returned to the caller at a more appropriate time to retry in the Retry-after header domain. This user may be available elsewhere, such as a phone-mail system, and so on. If we know that no other terminal system can answer this call, then we should return a status code of (Busy Everywhere).
4.25 487 Request Terminated
The request was terminated by bye or cancel. This response will never reply to the cancel request itself.
4.26 488 not acceptable here
This response and 606 (not acceptable) have the same meaning, but only the specific resources indicated by Request-uri are unacceptable, and requests from other places may be acceptable.
The body of the message containing the media compatibility description can appear in the answer and be normalized according to the Accept header field in the Invite request (if there is no Accept header field, then APPLICATION/SDP). This response is like the message body that answers the options request (OK).
4.27 491 Request Pending
In the same conversation, the request received by UAS has a dependent request being processed. 14.2 Describes how such a situation should be resolved.
4.28 493 undecipherable
The UAS received a request that contained an encrypted mime and did not know or provided the appropriate decryption key. This response can contain a single package containing the appropriate public key, which is used to encrypt the packet in the UAS communication. Details are described in section 23.2.
5 Server Failure 5xx
A 5xx response is a failure response that is given when the server itself fails.
5.1 Server Internal Error
The server encountered an unknown situation and could not continue processing the request. The client can display a specific error condition, and can retry the request in a matter of seconds.
If this condition is temporary, the server should retry the request after the Retry-after header domain flags the client for a few seconds.
5.2 501 Not implemented
The server did not implement the related request function. This answer should be returned when UAS does not recognize the requested method and is not able to support this method for every user. (Proxy forwards the request regardless of the requested method).
Note that 405 (method not allowed) is because the server implements this request method, but this request method is not supported in a particular request.
5.3 502 Bad Gateway
If the server is present as a gateway or proxy, an illegal response is received from the downstream server (the response request is forwarded by the server to the downstream server in order to complete the request).
5.4 503 Service Unavailable
The server is temporarily unavailable due to temporary overloading or server management. The server can add a retry-after to the response to allow the client to retry the request. If no retry-after indicates, the client must be treated as if it received a (Server Internal Error) reply.
The client (proxy or UAC) receives 503 (Service unavailable) should attempt to forward this request to another server for processing. And within the time specified in the Retry-after header domain, no other requests should be forwarded to this server.
As an alternative to 503 (Service unavaliable), the server can either reject the connection or discard the request.
5.5 504 Server Time-out
The server did not receive a prompt response on an external server. This external server is required for this server to access the processing of this request. If the Expires header field in the request received from the upstream server times out, then 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 is unable to process a request with the same major version number provided by the client, which can cause such an error message.
5.7 Message to Large
The server cannot process the request because the message length exceeds the length of the processing.
6 Global Failures 6xx
6XX response means that the server has a final message for a particular user, not just a specific instance of Request-uri.
6.1 Busy Everywhere
The terminal system of the called Party is successfully contacted, but the called party is in a busy state and is not going to answer the call. This answer can be more explicit by adding a Retry-after header domain to tell the caller how long later the call can continue. The called Party should use 603 (decline) if the called Party does not wish to indicate the reason for the rejection. This answer can only be used when the terminal system knows that no other endpoint, such as a voice mail system, can access the user. Otherwise, a 486 (Busy here) response should be returned.
6.2 603 decline
When the device is successfully accessed to the called party, but the user does not want to reply explicitly. This answer can be more explicit by adding a Retry-after header domain to tell the caller how long later the call can continue. This response can only be given if the terminal knows that no other terminal device can respond to the potential energy of the call.
6.3 604 Does not Exists Anywhere
The server verifies the user information that is Request-uri in the request, where none exists
6.4 606 Not acceptable
When a UA is successfully contacted, 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 does not fully support the session description. The 606 (not acceptable) answer can include a reason list in the warning header field to explain why the session description cannot be supported. The warning reason codes are listed in section 20.43.
In the answer, a message body containing the media compatibility description can appear, and the format of the message body is normalized according to the format indicated by the Accept header field in the Invite request (if there is no Accept header field, then APPLICATION/SDP), Just like the message in the answer to the Options Pro (OK).
We hope that these media consultations are not often required, and that this media negotiation may not be required when a new user is invited to a session that already exists. This depends on whether the invited initializer needs to process 606 (not acceptable).
This response can only be issued if the client knows that no other terminal can handle the request.

Http Status Code