HTTP/1.1 has several charactersitics that require re-engineering 1.0 code. Here are some notes I made alopng the way and more ramblings that occured to me later.
A client must assume that a site does not support persistence until it gets back an HTTP/1.1 reply or a "Connection: Keep-alive" header.
The client app must be prepared for a connection disappearing at any time, for instance, when a server has noticed that the connection was idle for too long. The client may be expecting data for a request when the connection is broken. In most cases, the client will want to restart the request by re-establishing a connection, sending the query, and awaiting a reply.
Some of the MIME headers (HTTP version, persistance, timeout) that come back from the server will apply to more than the accompanying document. These should be stored in a data structure associated with the site.
Pipelining is the ability of the client to send multiple requests to the server without waiting on the server's reply between them. This allows both the client and server to fill packets to the MTU, resulting in fewer packets moving accross the network. It also allows for more efficient scheduling at either end as the OS's will have to make fewer upcalls through select returns.
As the replies come back from the server, the client must keep track of which request is to recieve data. Pipelining was implemented in libwww by giving the host object a request list called a pipeline. Requests areadded to the pipeline after being sent to the server. The first request in the pipeline (first in) is always the one that will recieve data from the server. Requests are remove from the pipeline as their replies are recieved.
The server may return several documents in the same connection. The server must be vigilent about the content lengths of the encapsulated protocols. To date, this includes any of these three protocols:
For efficiency's sake, the client is likely to read as large a buffer as possible from the net and read the documents from that buffer. Since the buffer is likely to span a document boundry, the client must keep track of the amount of the buffer used by each document.
If a server breaks a connection, the client must do a standard connection recovery. Additionally, all requests that have not recieved replies must be re-sent. In libwww, this is done by copying everything out of the pipeline to another pending list.
The apache server sets the maximum number of requests per connection. This is communicated to the client in a "Keep-alive" mime header. A client can use this information to limit the number of requests that it sends to the server. Any extraneous requests will be have to be reposted when the server closes the connection. While a server need not limit the number of requests, a server that does should inform the client for efficiency's sake.
document: I use this term to mean any data being transported accross the HTTP connection. Perhaps "data" would be more appropriate, but "document" reflects the most common model of an HTML page being served.
site: The portion of the URL associated with <access scheme>://<domain address | IP address>:<port>
This page maintained by Eric Prud'hommeuax (eric@w3.org)