HTTP/1.1

Révolutionnaire ?

La RFC2616 décrivant HTTP/1.1 est assez conséquente (175 pages). Ceci dit, il n'y a pas de franche différence entre HTTP/1.1 et HTTP/1.0. HTTP/1.1 est plutôt une sorte d'ultime amélioration de HTTP/1.0 : une quasi parfaite utilisation et gestion des ressources avec un mécanisme de cache particulièrement amélioré. La préoccupation principale ne se trouve plus dans la façon d'acheminer la ressource, elle se situe plutôt désormais dans la rationnalisation du système dans son ensemble : le dialogue entre le client et le serveur doit être aussi clair et précis que possible, et ne doit circuler sur le réseau que le strict nécessaire. Dans ce sens, la connexion entre le client et le serveur reste désormais ouverte après la première requête, histoire de laisser le temps au client de récupérer d'autres fichiers (notamment les images contenues dans une page web). Le protocole essaie aussi d'introduire une "personnalisation" des requêtes avec la négociation de contenu, l'idée étant de fournir le document répondant au mieux aux besoins de l'utilisateur.

HTTP/1.1 complète également HTTP/1.0 par des statuts et des méthodes supplémentaires, et un mécanisme d'authentification par challenge (méthode "digest"). Ajoutons également une amélioration notable du système de cache, mais les bases du protocole restent celles de HTTP/1.0 : le message comporte toujours un en-tête avec un statut pour la réponse et un corps divisé comme dans HTTP/1.0 avec une entité.

Les formats de la requête et de la réponse ne changent pas par rapport à HTTP/1.0 : on y retrouve une méthode (requête) ou un statut (réponse) suivi d'en-têtes et d'un éventuel corps d'entité.

Nouveaux statuts

De nouveaux statuts font leur apparition. Leur rôle se situe surtout au niveau de la gestion des caches et du contrôle du trafic. La classe 1xx fait son apparition avec 2 statuts utilisés pour gérer directement le canal de transmission.

Nouvelles méthodes

Bien évidemment, les trois méthodes de base (GET, HEAD et POST) sont toujours là et restent toujours celles majoritairement utilisées. Cependant, 5 (4 vraies) autres méthodes font leur apparition :

• OPTIONS : permet au client de savoir les options de communication utilisables pour obtenir la ressource. L'intérêt est de savoir ce qu'on peut faire sans pour autant devoir demander une ressource.
• PUT : permet d'envoyer au serveur un document à enregistrer à l'URI spécifiée. Des statuts 2xx permettent de contrôler que tout c'est bien passé. C'est directement le serveur qui traite le document envoyé, et non pas un CGI comme cela est le cas pour la méthode POST.
• DELETE : efface la ressource spécifiée.
• TRACE : méthode de contrôle. Demande au serveur de renvoyer la requête telle qu'elle a été reçue.
• CONNECT : cette méthode est réservée pour les proxy permettant de faire du tunneling.

Les nouvelles méthodes sont là pour la gestion de la communication client-serveur et la gestion des documents du serveur. On peut donc désormais concevoir une interface d'administration simple et totalement "web". Il va de soi que ces méthodes ne sont pas autorisées à tout le monde.

Nouvelles directives

La liste des directives (48 au total) utilisables a été considérablement rallongée pour assurer le bon fonctionnement de toutes les nouveautés : gestion des caches, clarté du dialogue client-serveur, négociation de contenu, rationnalisation du canal de communication... La liste est trop longue pour figurer dans ce document. Elle est toutefois disponible sur cette page ou dans la RFC2616, pages 100 à 150.

Notons cependant que la directive "Host:" est désormais obligatoire dans toute requête HTTP/1.1, afin d'assurer une parfaite gestion des serveurs virtuels et une correcte utilisation des URL absolues et relatives (ce qui n'était pas le cas dans HTTP/1.0).

Les caches

L'idée des caches est la même qu'en HTTP/1.0, mais le mécanisme a été beaucoup amélioré dans HTTP/1.1. L'objectif principal est la réduction du nombre de requêtes "inutiles" : éviter au maximum de faire des requêtes complètes et éviter de renvoyer des documents complets autant que possible.

Concrètement, le cache doit s'assurer au maximum de la "fraîcheur" des documents. Cela passe par l'utilisation de nouvelles directives et de nouveaux statuts. Le cache doit pouvoir gérer 2 choses : les directives du serveur ("ne conserve pas ce document"...) et les souhaits du client ("je ne garde pas les documents plus de tant de temps").

En fait, le type de requêtes reste le même, mais des algorithmes et des règles plus précis sur la façon de calculer et gérer l'âge des documents ainsi que les dates d'expiration ont été écrits. Tout ceci n'avait pas été fait dans HTTP/1.0 ou alors de façon trop imprécise.

Le mécanisme complet est trop complexe pour figurer dans ce document. Pour une complète description, voir la RFC2616, pages 74 à 99.

Négociation de contenu

HTTP/1.1 essaie d'apporter une gestion "intelligente" des documents (voir gestion des caches). La négociation de contenu (content negociation) est un outil qui permet de renvoyer (ou récupérer selon le cas) le document qui répondra au mieux aux attentes du l'utilisateur. Il y a 3 mécanismes possibles pour cette négociation de contenu, mais aucune implémentation particulière n'est imposée.

Server-driven Negotiation

C'est le serveur qui va essayer de déterminer (avec un algorithme) le document qui va le mieux correspondre à l'utilisateur. Par exemple, si le serveur arrive à savoir que l'utilisateur est français (en vérifiant le nom du navigateur par exemple), il va essayer de renvoyer prioritairement les documents écrits en français.

L'intérêt est que c'est le serveur qui fait le calcul. Bien entendu, le client peut aider le serveur en renvoyant par exemple une directive "Accept-Language".

Il y a cependant quelques désavantages :

1. le serveur ne peut pas tout savoir des besoins de l'utilisateur (document à imprimer où à afficher à l'écran ?) et ne sait pas non plus "de quoi est capable" le client,
2. le client ne peut pas tout "dire" au serveur (problème de respect de la vie privée, et ce n'est pas dit que les données renvoyées sont pertinentes),
3. l'implémentation des algorithmes peut être délicate (détermination de l'algorithme puis intégration dans un serveur existant),
4. limitation des performances des caches.

Agent-driven Negotiation

Cette fois-ci, c'est le client HTTP qui essaie de de demander le "meilleur" document. La sélection se fait sur base d'une liste renvoyée par le serveur de toutes les représentations possibles pour le document demandé.

L'avantage de cette négociation est que généralement, c'est le client web qui est le mieux placé pour savoir ce qu'attend l'utilisateur (langue, encodage supporté). Cela intervient lorsque le serveur n'arrive pas à déterminer le "meilleur" document. Les caches joue dans cette négociation un rôle important.

Seul (gros) inconvénient : la négociation se fait toujours en 2 temps (demande de la liste des représentations puis demande du bon document). Cette négociation ne devient en fait efficace que lorsqu'il y a une véritable gestion des caches.

Les statuts 300 (Multiple Choices) et 406 (Not Acceptable) jouent un rôle important dans cette négociation.

Transparent Negotiation

C'est une combinaison des deux types précédents. L'idée est de faire travailler les caches à la place du serveur : sur une "Agent-driven Negotiation" (pour obtenir la liste des représentations possibles), et lorsque le cache "maîtrise" son contenu, il est alors capable de jouer le rôle du serveur avec une "Server-driven Negotiation".

Sécurité

Le mécanisme d'authentification de HTTP/1.0 n'a en revanche pas beaucoup changé. Un mécanisme d'authentification plus sûr (par challenge) a toutefois été mise en place pour résoudre les faiblesses de l'authentification "basic". Il s'agit de la méthode "digest" définie dans la RFC2617.

La RFC2616 donne également quelques recommandations pour la sécurité générale du serveur et de son contenu.

Conclusion

HTTP/1.1 est la version finale tant attendue de HTTP. Enormément d'améliorations ont été apportées, même par rapport à HTTP/1.0 qui était déjà un bond en avant dans le protocole. Toute la mécanique de base du protocole est désormais mise en place.

Par ailleurs, le principe des en-têtes fait qu'il est très facile d'étendre l'utilisation de HTTP au delà du simple échange de pages HTML entre un navigateur et un serveur Web. On peut par exemple utiliser HTTP pour faire dialoguer des applications métier entre elles (par exemple en utilisant des Web services).

HTTP/1.1 est devenu un protocole mature et stable, quasi universel et qui répond parfaitement au besoin initial. Peu (voire pas) d'évolutions du protocole sont à attendre. D'ailleurs, le W3C, l'organisme chargé de sa définition, a fermé l'activité HTTP. Les efforts sont désormais consacrées à des protocoles de plus haut niveau (basés sur HTTP) de type XML telles que les Web services.

Références

Les RFCs :

• RFC2616 : HTTP/1.1
• RFC2617 : authentification par les méthodes Basic et Digest

 format imprimable