Servlets are an exciting and important technology that ties Java to the Web, allowing programmers to write Java programs that create dynamic web content.Java Servlet Programming covers everything Java developers need to know to write effective servlets. It explains the servlet lifecycle, showing how to use servlets to maintain state information effortlessly. It also describes how to serve dynamic web content, including both HTML pages and multimedia data, and explores more advanced topics like integrated session tracking, efficient database connectivity using JDBC, applet-servlet communicaton, interservlet communication, and internationalization. Readers can use the book's numerous real-world examples as the basis for their own servlets.The second edition has been completely updated to cover the new features of Version 2.2 of the Java Servlet API. It introduces chapters on servlet security and advanced communication, and also introduces several popular tools for easier integration of servlet technology with dynamic web pages. These tools include JavaServer Pages (JSP), Tea, XMLC, and the Element Construction Set.In addition to complete coverage of 2.2 specification, Java Servlet programming, 2nd Edition, also contains coverage of the new 2.3 final draft specification.
About the Author
Jason Hunter is Senior Technologist with CollabNet, a company that provides tools and services for open source style collaboration. In addition to authoring Java Servlet Programming, he is publisher of Servlets.com, creator of the com.oreilly.servlet library, a contributor to the Apache Jakarta project that creates Tomcat (starting on the project when it was still Sun internal), a member of the expert groups responsible for Servlet/JSP and JAXP API development, and he holds a seat on the JCP Executive Committee overseeing the Java platform, as a representative of the Apache Software Foundation. He also writes columns for JavaWorld, and speaks at many programming and open source conferences. Most recently he co-created the open source JDOM library to enable optimized Java and XML integration, and he leads the expert group responsible for JDOM development. Jason graduated summa cum laude from Willamette University (Salem, Oregon) in 1995 with a degree in computer science. He began programming in Java in the summer of 1995 and has been involved with servlets and related server-side technologies since December 1996. If by some miracle you don't find him at work, he's probably out hiking in the mountains.
William Crawford has been developing web-based enterprise applications since 1995, including one of the first web-based electronic medical record systems (at Children's Hospital in Boston) and some of the first enterprise-level uses of Java. He has consulted for a variety of institutional clients, including Boston Children's Hospital, Harvard Medical Center, numerous startups and several Fortune 500 companies. Prior to an acquisition he was CTO of Invantage, Incorporated in Cambridge, MA. He received a degree in history and economics from Yale University. He is the co-author of Java Servlet Programming, 2nd Edition, Java Enterprise in a Nutshell, 2nd Edition, and two forthcoming O'Reilly titles. Will is currently Principal Software Architect at Perceptive Informatics, Inc.Massachusetts, provider of software and services to the pharmaceutical industry. He can be reached at http://www.williamcrawford.info
Read an Excerpt
Chapter 2: HTTP SERVLET BASICS
HTTP Servlet Basics
This chapter provides a quick introduction to some of the things an HTTP servlet can do. For example, an HTTP servlet can generate an HTML page, either when the servlet is accessed explicitly by name, by following a hypertext link, or as the result of a form submission. An HTTP servlet can also be embedded inside an HTML page, where it functions as a server-side include. Servlets can be chained together to produce complex effects-one common use of this technique is for filtering content. Finally, snippets of servlet code can be embedded directly in HTML pages using a new technique called Java Server Pages.
Although the code for each of the examples in this chapter is available for download (as described in the Preface), we would suggest that for these first examples you deny yourself the convenience of the Internet and type in the examples. It should help the concepts seep into your brain.
Don't be alarmed if we seem to skim lightly over some topics in this chapter. Servlets are powerful and, at times, complicated. The point here is to give you a general overview of how things work, before jumping in and overwhelming you with all of the details. By the end of this book, we promise that you'll be able to write servlets that do everything but make tea.
Before we can even show you a simple HTTP servlet, we need to make sure that you have a basic understanding of how the protocol behind the Web, HTTP, works. If you're an experienced CGI programmer (or if you've done any serious server-side web programming), you can safely skip this section. Better yet, you might skim it to refresh your memory about the finer points of the GET and POST methods. If you are new to the world of server-side web programming, however, you should read this material carefully, as the rest of the book is going to assume that you understand HTTP. For a more thorough discussion of HTTP and its methods, see Web Client Programming by Clinton Wong (O'Reilly).
Requests, Responses, and Headers
HTTP is a simple, stateless protocol. A client, such as a web browser, makes a request, the web server responds, and the transaction is done. When the client sends a request, the first thing it specifies is an HTTP command, called a method, that tells the server the type of action it wants performed. This first line of the request also specifies the address of a document (a URL) and the version of the HTTP protocol it is using. For example:
This request uses the GET method to ask for the document named intro html using HTTP Version 1.0. After sending the request, the client can send optional header information to tell the server extra information about the request, such as what software the client is running and what content types it understands. This information doesn't directly pertain to what was requested, but it could be used by the server in generating its response. Here are some sample request headers:
User-Agent: at: Mozilla /4.0 (compatible; MSIE 4, windows 95)
Accept image/gif, image/jpeg, text/*, */*
The User-Agent header provides information about the client software, while the Accept header specifies the media (MIME) types that the client prefers to accept. (We'll talk more about request headers in the context of servlets in Chapter 4, Retrieving Information.) After the headers, the client sends a blank line, to indicate the end of the header section. The client can also send additional data, if appropriate for the method being used, as it is with the, POST method that we'll discuss shortly. If the request doesn't send any data, it ends with an empty line.
After the client sends the request, the server processes it and sends back a response. The first line of the response is a status line that specifies the version of the HTTP protocol the server is using, a status code, and a description of the le. For example:
This status line includes a status code of 200, which indicates that the request was successful, hence the description "OK" Another common status code is 404, with the description "Not Found" - as you can guess, this means that the requested document was not found. Chapter 5, Sending HTML Information, discusses common status codes and how you can use them in servlets, while Appendix C, HTTP Status Codes, provides a complete list of HTTP status codes. After the status line, the server sends response headers that tell the client things like what software the server is running and the content type of the server's response. For example:
Date: Saturday, 23-May-98 03:25:12 GMT
server: Javawebserver/1.1.1 MIME-
version: 1.0 Content-type: text/html
content-length: 1029 Last-modified:
Thursday, 7-May-98 12:15:35 GMT
The Server header provides information about the server software, while the content-type header specifies the MIME type of the data included with the response. (We'll also talk more about response headers in Chapter 5.) The server sends a blank line after the headers, to conclude the header section. If the request was successful, the requested data is then sent as part of the response. Otherwise, the response may contain human-readable data that explains why the server couldn't fulfill the request.
GET and POST
When a client connects to a server and makes an HTTP request, the request can be of several different types, called methods. The most frequently used methods are GET and POST. Put simply, the GET method is designed for getting information (a document, a chart, or the results from a database query), while the POST method is designed for posting information (a credit card number, some new chart data, or information that is to be stored in a database). To use, a bulletin board analogy, GET is for reading and POST is for tacking up new material.
The GET method, although it's designed for reading information, can include as part of the request some of its own information that better describes what to get such as an x, y scale for a dynamically created chart. This information is passed as a sequence of characters appended to the request URL in what's called a query string. Placing the extra information in the URL in this way allows the page to be bookmarked or emailed like any other. Because GET requests theoretically shouldn't need to send large amounts of information, some servers limit the length of URLs and query strings to about 240 characters.
The POST method uses a different technique to send information to the server because in some cases it may need to send megabytes of information. A POST request passes all its data, of unlimited length, directly over the socket connection as part of its HTTP request body. The exchange is invisible to the client. The URL doesn't change at all. Consequently, POST requests cannot be bookmarked or emailed or, in some cases, even reloaded. That's by design-information sent to the server. such as your credit card number, should be sent only once....
Table of Contents
- Chapter 1: Introduction
- Chapter 2: HTTP Servlet Basics
- Chapter 3: The Servlet Lifecycle
- Chapter 4: Retrieving Information
- Chapter 5: Sending HTML Information
- Chapter 6: Sending Multimedia Content
- Chapter 7: Session Tracking
- Chapter 8: Security
- Chapter 9: Database Connectivity
- Chapter 10: Applet-Servlet Communication
- Chapter 11: Servlet Collaboration
- Chapter 12: Enterprise Servletsand J2EE
- Chapter 13: Internationalization
- Chapter 14: The Tea Framework
- Chapter 15: WebMacro
- Chapter 16: Element Construction Set
- Chapter 17: XMLC
- Chapter 18: JavaServer Pages
- Chapter 19: Odds and Ends
- Chapter 20: What’s New in the Servlet 2.3 API
- Servlet API Quick Reference
- HTTP Servlet API Quick Reference
- Deployment Descriptor DTD Reference
- HTTP Status Codes
- Character Entities
Most Helpful Customer Reviews
The book explores the servlet programming to a great depth. Exposes the great power of java servlets.The examples in the book are very useful for a developer.