Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

The Structure of an HTTP Response

An HTTP response, like a request, has a three-part structure:

<HTTP-version> <status-code> <reason-phrase>

The <HTTP-version> component reports the HTTP version used. It can only take the values HTTP/1.0 and HTTP/1.1. The <status-code> component contains a response status code. This is a three-digit number whose first digit defines the general response category:

100–199 are informational
200–299 show successful page access
300–399 redirect the request
400–499 are client errors
500–599 are server errors

The <reason-phrase> component provides a textual description of the response code.

The following example shows the successful response header from a request to browse the URI http://localhost:8080/index.html issued by a Tomcat server:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 6827
Connection: close
Date: Tue, 02 Apr 2002 13:30:12 GMT
ETag: "6827-1013538288000"
Server: Apache Tomcat/4.0.2 (HTTP/1.1 Connector)
Last-Modified: Tue, 12 Feb 2002 18:24:48 GMT

... <body omitted>

This example shows that a response includes header fields used to pass additional information back to the client. A servlet can define most of the header fields in a response. When Tomcat returns a static HTML page, the following header fields are defined:

Header Field



Defines the MIME type of the response body


Defines the number of bytes in the body


Used for connection persistence, as described in the later section "Persistent Connections"


Defines the date and time when the server issued the response


Defines a unique Entity Tag for this page, which can be used to improve the local caching of Web pages (see the later section "Client Page Caching")


Defines the server type and version


Defines the date when the HTML was last modified (from the time stamp on the HTML file)

Setting the Content-Type, Content-Length, Last-Modified, and ETag header fields within a servlet is discussed in Chapter 7, "The Web Application Environment."

A list of commonly occurring HTTP response codes is shown in Table 3.2. Knowledge of these response codes will assist you in debugging any problems with your Web applications. Note that a 500 series response often occurs if you have a problem with the configuration for your servlets, or if the servlet fails to run correctly (such as might occur when an uncaught exception is thrown).

Table 3.2 Common HTTP Response Codes



200 OK

Standard response for the successful request of a page.

301 Moved Permanently

The requested resource has been moved to a new location. The Location header indicates the URI of the new location. The client should request the page from this new URI.

304 Not Modified

This is returned when a client requests a page and specifies the If-modified-since header in the request. The server will return code 304 rather than 200 if the page has not changed since the indicated modification date. This protocol is used to improve efficiency when a browser is caching local copies of Web pages.

307 Temporary Redirect

The requested resource has been temporarily moved to a new location. The Location header indicates the URI of the new location. The client should request the page from this new URI. If you request the URI http://localhost:8080/ from Tomcat, you will get this response code, together with the header Location=http:// localhost:8080/index.html.

401 Unauthorized

Used when a client is not authorized to access a resource. This response is covered in more detail in Chapter 14, "Access Control."

403 Forbidden

Access to the resource is denied, and the server might supply further information in the response body.

404 Not Found

The requested URI was not found on the server. This response might also be used to deny access without giving further information.

414 Request-URI Too Long

This is returned when a GET URI is too long for the server to process.

500 Internal Server Error

Unknown internal error. In Tomcat, this is often a result of errors in the XML configuration files for a Web application (see Chapter 4, "Basic Principles of Servlets" and Appendix B, "Template web.xml File").

503 Service Unavailable

This can be used by a servlet to show that an external resource (perhaps a database) is not available. The client can retry the request at a later time.

Setting the response code from within a servlet is also discussed in Chapter 7.

  • + Share This
  • 🔖 Save To Your Account