高校学生公寓管理系统_外文翻译(范文).doc

外文文献资料

HTTP and Servlet Basics

Let's start off this chapter by defining the term web application. We've all seen

regular client-side applications, but what exactly is a web application? Loosely, it

can be defined as an application running on a server a user accesses through a thin,

general-purpose client. Today, the most common client is a web browser on a PC

or workstation, but other kinds of clients are rapidly joining the party, such as

wireless PDAs, cell phones, and other specialized devices.

is for.

The communication model defined by HTTP forms the foundation for all web

application design. A basic understanding of HTTP is key to developing

applications that fit within the constraints of the protocol, no matter which server-

side technology you use. In this chapter, we look at the most important details of

HTTP you need to be aware of as a web application developer.

One other item: this book is about using JSP as the server-side technology.

JSP is based on the Java servlet technology. Both technologies share a lot of

terminology and concepts, so knowing a bit about servlets will help you even when

you develop pure JSP applications. To really understand and use the full power of

corresponding to the resource (or a response with an error message if it can't

process the request for some reason). A resource can be a number of things, such as

a simple HTML file returned verbatim to the browser or a program that generates

the response dynamically.

This simple model implies three important facts you need to be aware of:

HTTP is a stateless protocol. This means that the server doesn't keep any

information about the client after it sends its response, and therefore it can't

recognize that multiple requests from the same client may be related.

Web applications can't easily provide the kind of immediate feedback

typically found in standalone GUI applications such as word processors or

the request on the client. For example, HTTP doesn't allow a web server to

differentiate between an explicit request caused by clicking a link or submitting a

form and an implicit request caused by resizing the browser window or using the

browser's Back button. In addition, HTTP doesn't contain any means for the server

to invoke client specific functions, such as going back in the browser history list or

sending the response to a certain frame. Also, the server can't detect when the user

closes the browser.

Over the years, people have developed various tricks to overcome the first

problem; HTTP's stateless nature. The other two problems—no immediate

feedback and no details about how the request is made—are harder to deal with,

in the browser's address field. To send a request, the browser needs to know which

server to talk to and which resource to ask for. This information is specified by an

HTTP Uniform Resource Locator (URL):

http://www.gefionsoftware.com/index.html

The first part of the URL shown specifies that the request is made using the

HTTP protocol. This is followed by the name of the server, in this case

www.gefionsoftware.com. The web server waits for requests to come in on a

specific TCP/IP port. Port number 80 is the standard port for HTTP requests. If the

web server uses another port, the URL must specify the port number in addition to

the server name. For example:

Uniform Resource Name (URN), which is a globally unique identifier that is valid

no matter where the resource is located. HTTP deals only with the URL variety.

The terms URI and URL are often used interchangeable, and unfortunately, they

have slightly different definitions in different specifications. I'm trying to use the

terms as defined by the HTTP/1.1 specification (RFC-2616), which is pretty close

to how they are also used in the servlet and JSP specifications. Hence, I use the

term URL only when the URI must start with http (or https, for HTTP over an

encrypted connection) followed by a server name and possibly a port number, as in

the previous examples. I use URI as a generic term for any string that identifies a

resource, where the location can be deduced from the context and isn't necessarily

The request line starts with the request method name, followed by a resource

identifier and the protocol version used by the browser:

GET /index.html HTTP/1.1

The most commonly used request method is named GET. As the name

implies, a GET request is used to retrieve a resource from the server. It's the default

request method, so if you type a URL in the browser's address field, or click on a

link, the request is sent as a GET request to the server.

The request headers provide additional information the server may use to

process the request. The message body is included only in some types of requests,

like the POST request discussed later.

Accept-Charset : iso-8859-1,*,utf-8

The request line specifies the GET method and asks for the resource named

/index.html to be returned using the HTTP/1.1 protocol version. The various

headers provide additional information.

The Host header tells the server the hostname used in the URL. A server may

have multiple names, so this information is used to distinguish between multiple

virtual web servers sharing the same web server process.

The User-Agent header contains information about the type of browser

making the request. The server can use this to send different types of responses to

different types of browsers. For instance, if the server knows whether Internet

capabilities of the browser and the user's preferences, such as use a supported

image format and the preferred language. These are just a few of the headers that

can be included in a request message.

The resource identifier (URI) doesn't necessarily correspond to a static file on

the server. It can identify an executable program, a record in a database, or pretty

much anything the web server knows about. That's why the generic term resource

is used. In fact, there's no way to tell if the /index.html URI corresponds to a file or

something else; it's just a name that means something to the server. The web server

is configured to map these unique names to the real resources.

2.1.2 Responses in Detail

request is handled; all it cares about is getting a response.

The response message looks similar to the request message. It consists of

three things: a status line, response headers, and an optional response body. Here's

an example:

HTTP/1.1 200 OK

Last-Modified: Mon, 20 Dec 2002 23:26:42 GMT

Date: Tue, 11 Jan 2003 20:52:40 GMT

Status: 200

Content-Type: text/html

Servlet-Engine: Tomcat Web Server/5.0