Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Application Server 7 Developer's Guide to NSAPI

Appendix E
HyperText Transfer Protocol

The HyperText Transfer Protocol (HTTP) is a protocol (a set of rules that describes how information is exchanged) that allows a client (such as a web browser) and an application server to communicate with each other.

HTTP is based on a request/response model. The browser opens a connection to the server and sends a request to the server.

The server processes the request and generates a response which it sends to the browser. The server then closes the connection.

This appendix provides a short introduction to a few HTTP basics. For more information on HTTP, see the IETF home page at:

http://www.ietf.org/home.html

This appendix has the following sections:


Compliance

Sun ONE Application Server 7 supports HTTP 1.1. Previous versions of the server supported HTTP 1.0. The server is conditionally compliant with the HTTP 1.1 proposed standard, as approved by the Internet Engineering Steering Group (IESG) and the Internet Engineering Task Force (IETF) HTTP working group.

For more information on the criteria for being conditionally compliant, see the Hypertext Transfer Protocol—HTTP/1.1 specification (RFC 2068) at:

http://www.ietf.org/rfc/rfc2068.txt?number=2068


Requests

A request from a browser to a server includes the following information:

Request Method, URI, and Protocol Version

A browser can request information using a number of methods. The commonly used methods include the following:

Request Headers

The browser can send headers to the server. Most are optional.

The following table shows commonly used request headers. The left column lists request headers, and the right column lists descriptions of those headers.

Table E-1  Common request headers

Request header

Description

Accept

The file types the browser can accept.

Authorization

Used if the browser wants to authenticate itself with a server; information such as the username and password are included.

User-agent

The name and version of the browser software.

Referer

The URL of the document where the user clicked on the link.

Host

The Internet host and port number of the resource being requested.

Request Data

If the browser has made a POST or PUT request, it sends data after the blank line following the request headers. If the browser sends a GET or HEAD request, there is no data to send.


Responses

The server’s response includes the following:

HTTP Protocol Version, Status Code, and Reason Phrase

The server sends back a status code, which is a three-digit numeric code. The five categories of status codes are:

The following table shows commonly used HTTP status codes. The left column lists status codes, and the right column lists descriptions of those codes.

Table E-2  Common HTTP status codes 

Status code

Meaning

200

OK; request has succeeded for the method used (GET, POST, HEAD).

201

The request has resulted in the creation of a new resource reference by the returned URI.

206

The server has sent a response to byte range requests.

302

Found. Redirection to a new URL. The original URL has moved. This is not an error; most browsers will get the new page.

304

Use a local copy. If a browser already has a page in its cache, and the page is requested again, some browsers relay to the application server the “last-modified” timestamp on the browser’s cached copy. If the copy on the server is not newer than the browser’s copy, the server returns a 304 code instead of returning the page, reducing unnecessary network traffic. This is not an error.

400

Sent if the request is not a valid HTTP/1.0 or HTTP/1.1 request. For example HTTP/1.1 requires a host to be specified either in the Host header or as part of the URI on the request line.

401

Unauthorized. The user requested a document but didn’t provide a valid username or password.

403

Forbidden. Access to this URL is forbidden.

404

Not found. The document requested isn’t on the server. This code can also be sent if the server has been told to protect the document by telling unauthorized people that it doesn’t exist.

408

If the client starts a request but does not complete it within the keep-alive timeout configured in the server, then this response will be sent and the connection closed. The request can be repeated with another open connection.

411

The client submitted a POST request with chunked-encoding, which is of variable length. However, the resource or application on the server requires a fixed length - a content-length header to be present. This code tells the client to resubmit its request with content-length.

413

Some applications cannot handle very large amounts of data, so they return this code.

414

The URI is longer than the maximum the application server is willing to serve.

416

Data was requested outside the range of a file.

500

Server error. A server-related error occurred. The server administrator should check the server log to see what happened.

503

Sent if the quality of service mechanism was enabled and bandwidth or connection limits were attained. The server will then serve requests with that code. For more information about quality of service, see the Sun ONE Application Server Performance Tuning, Sizing, and Scaling Guide.

Response Headers

The response headers contain information about the server and the response data.

The following table shows commonly used response headers. The left column lists response headers, and the right column lists descriptions of those headers.

.

Table E-3  Common response headers

Response header

Description

Server

The name and version of the application server.

Date

The current date (in Greenwich Mean Time).

Last-modified

The date when the document was last modified.

Expires

The date when the document expires.

Content-length

The length of the data that follows (in bytes).

Content-type

The MIME type of the following data.

WWW-authenticate

Used during authentication and includes information that tells the browser software what is necessary for authentication (such as username and password).

Response Data

The server sends a blank line after the last header. It then sends the response data such as an image or an HTML page.


Buffered Streams

Buffered streams improve the efficiency of network I/O (for example the exchange of HTTP requests and responses) especially for dynamic content generation. Buffered streams are implemented as transparent NSPR I/O layers, which means even existing NSAPI plugins can use them without any change.

The buffered streams layer adds following features to the Sun ONE Application Server:

The improved connection handling and response length header generation provided by buffered streams also addresses the HTTP 1.1 protocol compliance issues where absence of the response length headers is regarded as a category 1 failure. In previous Enterprise Server versions it was the responsibility of the dynamic content generation programs to send the length headers. If a CGI script did not generate the content-length header, the server had to close the connection to indicate the end of the response, breaking the keep-alive mechanism. However, it is often very inconvenient to keep track of response length in CGI scripts or servlets, and as an application platform provider, the application server is expected to handle such low-level protocol issues.

Output buffering has been built in to the NSAPI functions that transmit data, such as net_write (see Chapter 6, "NSAPI Function Reference"). You can specify the following Service SAF parameters that affect stream buffering, which are described in detail in Chapter 2, "Predefined SAFs and the Request Handling Process".

The UseOutputStreamSize, ChunkedRequestBufferSize, and ChunkedRequestTimeout parameters also have the equivalent init.conf directives; see the Sun ONE Application Server Administrator’s Configuration File Reference. The obj.conf parameters override the init.conf directives.


Note

The UseOutputStreamSize parameter can be set to zero in the obj.conf file to disable output stream buffering. For the init.conf file, setting UseOutputStreamSize to zero has no effect.


To override the default behavior when invoking an SAF that uses one of the NSAPI functions net_read or netbuf_grab (see Chapter 6, "NSAPI Function Reference"), you can specify the value of the parameter in obj.conf, for example:

Service fn="my-service-saf" type=perf UseOutputStreamSize=8192



Previous      Contents      Index      Next     


Copyright 2003 Sun Microsystems, Inc. All rights reserved.