- Shopping Bag ( 0 items )
The Java Servlet API, introduced as the first standard extension to Java, provides a generic mechanism to extend the functionality of any kind of server. Servlets are most commonly used, however, to extend Web servers, performing tasks traditionally handled by CGI programs. Web servers that can support servlets include: Apache, Netscape's FastTrack and Enterprise Servers, Microsoft's IIS, O'Reilly's WebSite, and JavaSoft's Java Web Server.
The beauty of servlets is that they execute within the Web server's process space and they persist between invocations. This gives servlets tremendous performance benefits over CGI programs. Yet because they're written in Java, servlets are far less likely to crash a Web server than a C-based NSAPI or ISAPI extension. Servlets have full access to the various Java APIs and to third-party component classes, making them ideal for use in communicating with applets, databases, and RMI servers. Plus, servlets are portable between operating systems and between servers -- with servlets you can "write once, serve everywhere."
Java Servlet Programming covers everything you need to know to write effective servlets and includes numerous examples that you can use as the basis for your own servlets. The book explains the servlet life cycle, showing how you can use servlets to maintain state information effortlessly. It also describes how to serve dynamic Web content, including both HTML pages and multimedia data. Finally, it explores more advanced topics like integrated session tracking, efficient database connectivity using JDBC, applet-servlet communication, inter-servlet communication, and internationalization.
The popularity of Java server side programming has markedly increased with the resolution of a number of portability issues and with the acceptance of thin clients. Key components of server side development are pluggable extensions (or servlets) that enhance server functionality. This publication takes you into the internals of servlets. It assumes that you are programming with Java, HTTP, APIs and database connectivity.
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....
Posted September 19, 2002
Posted March 3, 2011
No text was provided for this review.