start page | rating of books | rating of authors | reviews | copyrights

Book Home Java Servlet Programming Search this book

Chapter 5. Sending HTML Information

Contents:

The Structure of a Response
Sending a Normal Response
Using Persistent Connections
HTML Generation
Status Codes
HTTP Headers
When Things Go Wrong

In the previous chapter, we learned that a servlet has access to all sorts of information--information about the client, about the server, about the request, and even about itself. Now it's time to look at what a servlet can do with that information, by learning how it sets and sends information.

The chapter begins with a review of how a servlet returns a normal HTML response, fully explaining some methods we glossed over in previous examples. Next we cover how to reduce the overhead involved in returning a response by keeping alive a connection to the client. Then we explore the extra things you can do with HTML and HTTP, including using support classes to objectify the HTML output, returning errors and other status codes, sending custom header information, redirecting the request, using client pull, detecting when the user disconnects, and writing data to the server log.

5.1. The Structure of a Response

An HTTP servlet can return three kinds of things to the client: a single status code, any number of HTTP headers, and a response body. A status code is an integer value that describes, as you would expect, the status of the response. The status code can indicate success or failure, or it can tell the client software to take further action to finish the request. The numerical status code is often accompanied by a "reason phrase" that describes the status in prose better understood by a human. Usually, a status code works behind the scenes and is interpreted by the browser software. Sometimes, especially when things go wrong, a browser may show the status code to the user. The most famous status code is probably the "404 Not Found" code, sent by a web server when it cannot locate a requested URL.

We saw HTTP headers in the previous chapter when clients used them to send extra information along with a request. In this chapter, we'll see how a servlet can send HTTP headers as part of its response.

The response body is the main content of the response. For an HTML page, the response body is the HTML itself. For a graphic, the response body contains the bytes that make up the image. A response body can be of any type and of any length; the client knows what to expect by reading and interpreting the HTTP headers in the response.

A generic servlet is much simpler than an HTTP servlet--it returns only a response body to its client. It's possible, however, for a subclass of GenericServlet to present an API that divides this single response body into a more elaborate structure, giving the appearance of returning multiple items. In fact, this is exactly what HTTP servlets do. At the lowest level, a web server sends its entire response as a stream of bytes to the client. Any methods that set status codes or headers are abstractions above that.

It's important to understand this because even though a servlet programmer doesn't have to know the details of the HTTP protocol, the protocol does affect the order in which a servlet can call its methods. Specifically, the HTTP protocol specifies that the status code and headers must be sent before the response body. A servlet, therefore, should be careful to always set its status codes and headers before returning any of its response body. Some servers, including the Java Web Server, internally buffer some length of a servlet's response body (usually about 4K)--this allows you some freedom to set the status codes and headers even after a servlet has written a short amount of response body. However, this behavior is server implementation dependent, and as a wise servlet programmer, you'll forget all about it!



Library Navigation Links

Copyright © 2001 O'Reilly & Associates. All rights reserved.