Status Codes

 < Free Open Study > 

HTTP status codes are used by the HTTP server in the response to indicate the result of the request. The most commonly used codes are 200 OK meaning that the request was successful and the requested file or resource is enclosed in the body of the response, and 404 Not Found meaning that requested resource could not be found. However, there are many more codes available to indicate other conditions, such as the requested resource has been moved (permanently or temporarily), client or server errors and other details. These are not only used by web servers for static resources, but are also used for dynamic resources including servlets and JSPs.

The javax.servlet.http.HttpServletResponse class supports all HTTP/1.1 (and HTTP/1.0) status codes and web applications should make appropriate use of the status codes in their applications. For web applications with browsers as clients, the browser will be able to interpret the response status code correctly and display the resource or take the required action (e.g. a redirect). To ensure compatibility with HTTP/1.0 clients, if required, programmers should only use those status codes marked with "*" which indicates a status code that exists in HTTP/1.0 and on.

When working with Java client applications correct use of status codes can simplify the treatment of the returned data (if any), and convey information. Hence Java clients are recommended to check the status code during receiving the server's response.

The following table outlines the ranges of codes available and their general meanings.

Status Code Range





These codes are informational, indicating that the server has received the HTTP request and the client can continue the request.

As no 1xx codes were defined by HTTP/1.0, these should only be used with HTTP/1.1 clients, or under experimental or custom conditions.



2xx status codes indicate that the request was successfully received, understood and accepted by the server. Information/data may or may not be returned to the client depending on the specific code.



These response codes indicate that further action is required to complete the request. Only GET or HEAD requests may allow the client to automatically redirect on receiving this response. Other requests methods require user input according to the specifications.

Those clients automatically redirecting should limit the number of redirects (to prevent infinite or excessive loops). HTTP/1.1 does not specify a specific maximum number, but in HTTP/1.0 redirects are limited to five at a maximum.


Client Error

The 4xx series of status codes indicates that the client appears to have made an error, such as making a request for a resource that does not exist (or is forbidden to the client, or used bad syntax/badly formed request etc).

The server normally should include an entity containing an explanation of the error also indicating if the error situation is temporary or permanent (except for HEAD requests). Normally the client should display the entity to the user, which will explain the error. For web pages and HTML/browser requests the entity will be an HTML error page, however for Java applications, this may be a standard serialized error object explaining the problem.


Server Error

5xx status codes indicate that a server-side error occurred while processing the request. Most often these are as a result of a programmers error or in the case of high server load where the server has not enough resources to fulfill the request etc.

As for 4xx client errors, the server should included an entity in the response that explains the error situation and indicate whether this situation is temporary (e.g. server overload) or permanent. Again HEAD requests do not require the entity body. As before, for HTML/browser web requests this will normally include a HTML page explaining the error, and for Java client applications may include a serialized Java error object or other entity depending on the communication (e.g. XML).

The following tables covers all the HTTP/1.1 status codes and meanings and gives an explanation for each code. It also indicates the constant used in javax.servlet.http.HttpServletResponse for this code. Codes indicated with "*" were also included in the HTTP/1.0 specifications and can be safely used with all HTTP/1.0 and HTTP/1.1 clients.

Range: 1xx - Informational

Status Code


HttpServletResponse Constant





This indicates that the initial part of the request was successfully (so far) been received by the server and the client should continue by sending the remainder of the request, if any more exists. The client may ignore this message if it has completed the request.

In any case, after the request has been completed, the server must send a final response.

For Java web applications with Java clients this is useful for sending a request in a number of parts, which may help speed up the request processing.


Switching Protocols


This indicates that the server has understood the request and will process it. The server returns an Upgrade message header field indicating the preferred protocol. The server will automatically upgrade to the new protocol after the empty line ending this response. Different protocols should only be used when they improve the communication such as improving security or taking advantage of additional features in the new protocol.

Range: 2xx - Success

Status Code


HttpServletResponse Constant


200 *



This indicates that the request has succeeded normally. Depending on the request method used additional information will be returned to the client.

A GET request returns the requested resource. A HEAD request will return the entity header fields without any message body. The POST method will return the entity containing or describing the result of the action. The TRACE method will return the request message as received by the server.




This indicates that the server has successfully created the resource requested by the client on the server. This is not returned until after the resource is created (202 Accepted should be used if resource is not yet created).

The URI location(s) of the new resource are returned to the client.

202 *



This indicates that the request has been accepted but not completed yet. The request will be processed at a later point and may or may not be successful at this point. Whether it is successful or unsuccessful at the later point is not known by the client (unless there is a mechanism to check this).

This may be used, for example when data is stored on the server or database temporarily and only updated at specific intervals, such as trades to be settled etc.

Normally the response should include an indication of the current status of the request and when it will be processed, or other relevant information.


Non-Authoritative Information


This code is equivalent to the 200 OK response, however this indicates that the information contained within the response did not originate from the server, but from a local or other copy. In web terms this could be used by a proxy server serving cached content which cannot be verified due network problems etc.

204 *

No Content


This response is similar to the 200 OK response in that the request was successful, but in this case there is no content or no new content to return. There will be no message body to this request.


Reset Content


Similar to the previous code, the request was processed and the client should reset the view that caused the request to be made.

Examples of this include HTML or Java application/applet forms that should be reset after the data in the request has been processed.


Partial Content


The request generating this must have included a Range header field, and maybe an If-Range field, and this response code indicates that the data returned is the part specified by the Range requested.

Range: 3xx - Redirection

Status Code


HttpServletResponse Constant


300 *

Multiple Choices


This code indicates that more than one locations or representations are available for the request. The response should indicate the preferred (if any) option and include a list of choices.

For example, this could be used for servers serving browser clients and other clients (e.g. XML) and may include the location of the HTML representation of the information as default (for browsers that will automatically choose the default), with other choices such as XML available for other types of clients.

301 *

Moved Permanently


This indicates that the requested resource has been moved permanently to a new location given in the header field (and clients should update the location).

GET or HEAD requests may automatically redirect, however other request methods should not automatically redirect, at least until user agreement.

302 *



This indicates that the resource requested by the client has been moved temporarily and clients should return to the current URI to access the resource.

As with 301, the client may automatically redirect GET or HEAD requests, but other methods require user intervention.

HTTP/1.0 defined the message as Moved Temporarily while HTTP/1.1 defines it as Found. Hence why the constant name for this code is substantially different from the message.


See Other


This indicates that the requested resource exists under a different URI and this allows for the conversion of a POST request into a GET request on the new resource.

In case clients may use HTTP/1.0, code 302 may be a better alternative in some cases.

304 *

Not Modified


When a client makes a conditional GET request and the resource requested has not been modified, the server will return this status code indicating that the client has the latest version of the resource.

This can be useful where clients have to request and update large amounts of data, and the server can check if the data has been changed recently. This can be used when the client side data is up-to-date.


Use Proxy


This indicates that the requested resource must be accessed using the proxy indicated in the Location header field.


Temporary Redirect


This indicates that the resource requested by the client temporarily resides under a different URI (given in the Location field) and clients should return to the current URI to access the resource.

The client may automatically redirect GET or HEAD requests, but other methods require user intervention.

Range: 4xx - Client Error

Status Code


HttpServletResponse Constant


400 *

Bad Request


This code when sent from the server indicates that the client's request was incorrectly formed (i.e. syntactically incorrect) and the server cannot process the request. The client should not repeat the request as-is without making modifications.

401 *



This indicates that the client has requested a resource that requires user authentication that has not been supplied, or has failed authorization.

The response includes the WWW-Authenticate header field to which the client may reply with a suitable Authorization header field.

In web browsers this normally means that the user will be presented with a dialog box into which they can enter their username and password for authentication. In Java applications or applets the client should also provide a login box for the username and password or use a previously supplied username and password to authenticate the client to the server.


Payment Required


This code has been reserved for future use in connection with payment information, but has not yet been implemented or standardized.

403 *



The server has understood the client's request, but has refused the client access to the requested resource.

For requests other than HEAD requests the server may give a reason in the body. This is not an authentication problem and authentication information will not change the result.

This may be used in web applications where certain resources are protected, possibly by security stronger than HTTP types of security (e.g. own application algorithms etc), and where access is required though a specific gateway or where access is restricted to clients within certain limits (e.g. only within company networks or geographical domains).

404 *

Not Found


This is commonly used on web servers that cannot locate a resource at the requested URI. It means that the server does not know, or indicate, why the resource is unavailable. Where a server knows that the resource is permanently unavailable (with no forwarding location), it should return 410 Gone.

This commonly is seen on the Internet when web resources have been changed or updated and old links remain pointing to an old location for the removed or relocated resource.


Method Not Allowed


A server response returning this code is indicating that the request method of the client is not permitted for this resource. The server must include an Allow header to indicate acceptable request methods for this resource, in case the client may retry or reform the request using a different method.


Not Acceptable


This code can be returned where the mime type specified by the Content-Type header is not acceptable to the options specified by the client. Except for HEAD requests the server should include a list of options from which the user can chose.

It is not always preferable to send this message, and sometimes it may be better to return the response (in spite of the types indicated as accepted) with all content as per normal and let the client/user decide how to handle it (e.g. save it for future use). This is essentially a programmers decision based on the type of data involved.


Proxy Authentication Required


The server returns this code when the client must authenticate with the proxy. The client may repeat the same request with a suitable Proxy-Authorization field to authenticate.

This is similar to the 401 Unauthorized, however in this case the client is authenticating with the proxy.


Request Time-out


This is returned when the client fails to send its request within the timeout period of the server. The client can repeat the request later, if required.

This is normally used for multi part requests from the client.




The server will return this code when the request cannot be completed due to a conflict in the current state of the resource. This status code should only be returned when the client may be able to resolve the conflict, and if possible the response should contain information that will help the client resolve the problem.

The specifications envisage that these conflicts are most likely to occur in response to a PUT request in cases such as versioning conflicts. In Java terms this could occur when code or web applications are uploaded with inconsistent or incompatible versions or requiring specific versions of libraries (such as XML parsers) not available on the server. In this case the server should return information about the library (or other) conflict.




The 410 Gone status code is used to indicate when a resource has been removed permanently with no URI to forward the request to. Links to this resource should be removed.

Often the 404 Not Found code is used in place of this code, as it is not always practical to mark or configure every removed resource to have a 410 Gone status code returned in every case.


Length Required


This code is returned in the server's response when it requires the client to define the Content-Length header. The client could repeat the request adding in the Content-Length header.


Precondition Failed


If one of the clients request header field preconditions (If headers) fails, the server will return this code in the response.


Request Entity Too Large


When the server receives a request entity larger than it is configured or able to process it may return this response code.

In these cases, the Content-Length header (possibly with the 411 Length Required code) is normally used to perform the check, although a byte count of the request length may be used. The server may close the connection after reading the Content-Length and returning the code (or after the limit of bytes is reached).

If this occurs as a result of a temporary situation (e.g. high server load) the server can include a Retry-After header to indicate that the client could try again after the specified time.


Request-URI Too Large


This indicates that the URI used to make the request is too long, possibly as a result of a POST request being inappropriately converted into a GET request, or simply too much path or parameter information being supplied in the request.

Many servers limit the length of the URI that may be processed in a request and will return this code when that limit is exceeded.


Unsupported Media Type


A server will return this error code when the body of the request is in a format that the resource requested by the client is unable to handle.

This could be part of a PUT request or other request such a as POST request where the data supplied is in the incorrect, or unsupported format for the resource.

For example a servlet may be configured to handle data only in XML format and so is not configured to handle binary files, or serialized Java objects.


Requested range not satisfiable


The Range header of the request condition is not satisfiable by the response resource, as it does not overlap with the range of the potential response.


Expectation Failed


Clients may include an Expect header in the request, which if the server is unable to satisfy, will result in the server returning this code.

Range: 5xx - Server Error

Status Code


HttpServletResponse Constant


500 *

Internal Server Error


This indicates that an unexpected error has occurred within the server or resource processing the request and it is unable to carry out the request.

This often occurs as a result of an error (e.g. programmers error) in the resource (e.g. servlet) code or in the resource not being able to process an unexpected value for a request parameter. It may also occur when the request cannot be processed because another resource required by the requested resource is not available.

In Java terms this can mean that there is a processing error in a servlet as a result of programmer error, incorrect request parameters (normally the servlet should handle this gracefully and return a more appropriate error) or when a database, or other resource required by the servlet is unavailable. Again the code should normally handle this eventuality gracefully, but if an uncaught exception is thrown to the web container, this status code will be returned.

501 *

Not Implement ed


The server will return the 501 Not Implemented status code if the request requires functionality not supported by the server. This could appear when the request method is not supported or recognized by the server.

HTTP/1.0 servers would throw this error code if a request type that was introduced in HTTP/1.1 (e.g. OPTIONS or TRACE) was made to it.

502 *

Bad Gateway


This indicates that the HTTP server, while it was acting as a proxy or gateway server, received an invalid response from an upstream server. Then the proxy or gateway server returns this code indicating the problem.

503 *

Service Unavailable


When a server is overloaded it may return this code to indicate that it cannot handle the request due to the server load. It may indicate, with a Retry-After header, when the client should retry the request, otherwise the client should react as if it was a 500 Internal Server Error.

However a server that is overloaded may refuse connection or may be unable to handle the connection due to the overload.


Gateway Time-out


This indicates that the HTTP server, while it was acting as a proxy or gateway server, did not receive a response from an upstream server within the server's timeout period.

The upstream server may be any server or auxiliary server requested or needed to serve the request (e.g. HTTP, FTP, DNS etc).


HTTP Version not supported


The server that does not support the version of HTTP that the request is made in. The server's response should comprise an entity including a list of other protocols supported by that server, and if possible, describe why the HTTP version is not supported.

 < Free Open Study > 

Professional Java Servlets 2.3
Professional Java Servlets 2.3
ISBN: 186100561X
EAN: 2147483647
Year: 2006
Pages: 130 © 2008-2017.
If you may any questions please contact us: