HTTP/1.1

Is it a revolution?

The RFC2616, which describes HTTP/1.1, is quite long (75 pages), but it is not that much revolutionary regarding HTTP/1.0; we would rather say it is a kind of ultimate improvement if HTTP/1.0: it quite efficiently uses and manages resources (the cache mechanism has been dramatically improved). The main preoccupation no longer lies in resource conveyance, it rather lies in a rationalization of the system in the whole: the dialog between the client and the server must be as clear and accurate as possible, and only the network carries only what is strictly necessary. By this way, the connection between the client and the server is finally kept alive after the first request to allow the client to download any other required resource (especially images). The protocol also tries to introduce a personal touch into requests with the content negociation; the idea is to provide the most relevant document for the user.

HTTP/1.1 also completes HTTP/1.0 by additional status and methods, an authentication mechanism using challenges (the "digest" method). We can also notice an improvement of the cache system, but the basis is the same: the message consists of a header (for the status of the reply) and an body with an entity.

The request and response formats are the same as the ones from HTTP/1.0: there is a method (request) or a status (response) followed by headers and a possible entity's body.

New status

HTTP/1.1 introduces new status. They are almost used to manage caches and control the traffic. The 1xx class appears with 2 status used to handle transmission channels.

New methods

Obviously, the 3 standard methods (GET, HEAD and POST) are still here and are still the main ones. However, 5 (4 actually) new methods are defined in HTTP/1.1:

• OPTIONS: it allows a client to know what communication options are available to get the resource. The interest is to know what we can do without asking for a resource.
• PUT: is used to send a document to a server and to ask it to store it at the provided URI. 2xx status are used to control that everything is fine. permet d'envoyer au serveur un document à enregistrer à l'URI. The document is NOT sent to a CGI script, the server copies itself the file.
• DELETE: used to delete the given resource.
• TRACE: this method is used by a client to ask the server to send back the request it finally got.
• CONNECT: this method is not very well defined. It is reserved for proxies to build tunnels.

These new methods are here to manage the communication between the client and the server and to handle documents on the server. It is now possible to develop a complete web interface to manage a web server. Obviously these methods cannot be used by anybody.

New directives

The complete list of available directives (48 in total) has been dramatically completed to be sure all new innovations work fine: cache management, clarity of the client-server dialogue, content negociation, rationalization of the communication channel... The complete list of directives is to long to be put in this document; however, they all can be found on this page or in the RFC2616, pages 100 to 150.

Let's notice nevertheless that the "Host:" directive is now mandatory in any HTTP/1.1 request to guarantee that virtual servers and absolute and relative URIs are perfectly handled. This was not the case of HTTP/1.0.

Caches

The basic idea remains the same, but the mechanism has been really improved. The main goal is to reduce the number of "useless" requests: it is a matter of avoiding as much as possible complete requests and avoiding sending full documents as much as possible.

In concrete terms, a cache must be sure that all its cached documents are the latest ones. This is performed with new directives and new status. A cache must be able to manage 2 different things: server directives ("do not cache this document"...) and client wishes ("I don't keep this document for more than xxx hours").

Basically, the requests are the same but algorithms and rules are more accurate on the way to calculate and manage documents' ages as well as expiration dates. All this was not described or in a too vague way in HTTP/1.0.

The complet mechanism is too complexe to be described in this document. Anyway, you can find it in the RFC2616, pages 74 to 99.

Content negociation

HTTP/1.1 tries to bring a "smart" management of documents (see caches). Content negociation is a tool used to send (or retrieve) a document that is more likely to match the user's wishes. There are 3 possible mechanisms for this content negociation, but no special implementation is imperative.

Server-driven Negotiation

The server tries to determine (with a special algorithm) what document matches at best the user's wishes. For instance, is the server manages to guess the user is English (it can check the name of the web browser) it will first send the English version of the document.

The interest is that the server does the calculation. Of course, the client may give clues: it may send a "Accept-Languge" directive...

There are however drawbacks:

1. the server cannot guess everything about the user (does he want to print the document out or just display it on the screen?) and it cannot know what the client can do with the document,
2. the client cannot say everything to the server (problem of confidentiality and the data it sends may not be relevant),
3. the algorithm implementation may be tricky,
4. performance restrictions of caches.

Agent-driven Negotiation

For this negociation, it is the HTTP client that tries to determine the best profile for the document. A selection is performed according to a list of all possible documents the server has just sent.

The advantage of this negociation is that most of the time, the web client is more likely to know what would match the user's wishes (language, encoding format...). This negociation is used when the server is not able to determine the best document. Caches play a very important role in this mechanism.

There is only one (big) disadvantage: this negociation is performed in 2 steps (the client asks for the list of document and then asks for the good one). This negociation is really interesting only when cache systems are very efficient.

The 300 (Multiple Choices) and 406 (Not Acceptable) are also very important in this context.

Transparent Negotiation

This is actually the combination of the previous 2 systems. The idea is to make caches work in place of the server: with an Agent-Driven Negociation a very efficient cache system can replace the server as in a Server-Driven Negociation.

Security

The authentication mechanism of HTTP/1.0 has not been really improved. However a safer authentication mechanism (by challenge) has been developed to make up for the problems of the "Basic" authentication mechanism. This new mechanism is the "digest" method defined in the RFC2617.

The RFC2616 also contains some recommendations about security on web servers and their contents.

Conclusion

HTTP/1.1 is finally the HTTP version we were all waiting for. There are a lot of improvements, even regarding HTTP/1.0 that was already a leap forward for HTTP.

The basic mechanism of HTTP is from now on set, and in all likelihood few technical improvements will be done. What we should expect from the next HTTP versions is an answer to the new needs of the web: e-commerce, e-business... HTTP will certainly turn towards a high level service: HTTP is no longer a document transport protocol, it is a smart protocol.

Reference

RFCs:

• RFC2616 : HTTP/1.1
• RFC2617 : Basic and Digest authentication methods

 printable format