Le protocole HTTP 10 minutes pour comprendre HTTP/0.9 - Lacunes et limitations HTTP/1.0 HTTP/1.1 http://tic01.tic.ec-lyon.fr/~muller/cours-tdw/http.pdf http://tic01.tic.ec-lyon.fr/~muller/cours-tdw/httpbw.pdf Le protocole HTTP Le protocole HTTP 10 minutes pour comprendre Le protocole HTTP
Le principe client-serveur 1. Le client ouvre une connexion Serveur 2. Le client envoie une requête vers le serveur 3. Le serveur répond au client Client 4. Le serveur coupe la connexion (particulier à HTTP 1.0) Le protocole HTTP - 10 minutes pour comprendre - Une session HTTP/0.9 'manuelle' > telnet www.ec-lyon.fr 80 GET http://www.ec-lyon.fr/index.html <HTML> <HEAD> <TITLE> </TITLE> </HEAD> <BODY> </BODY> </HTML> Connection closed by foreign host > Le protocole HTTP - 10 minutes pour comprendre -
HTTP/0.9 HTTP - HyperText Transfer Protocol Conçu en 1990 lors de «l invention» du Web pour l échange de documents html (client-serveur) sur un réseau TCP/IP. Avantages : très simple indépendant de la nature des informations échangées indépendant de la couche transport (TCP et IP) Inconvénients : trop simple Le protocole HTTP - 10 minutes pour comprendre - Le protocole HTTP HTTP/0.9 - Lacunes et limitations Le protocole HTTP
Des connexions éphémères Ouverture / fermeture d une nouvelle connexion par document échangé (processus non instantané) Une page Web peut donner lieu à l échange de nombreux «documents» (images, applets, frames ) attente de l utilisateur et saturation du réseau les clients ouvrent plusieurs connexions simultanées avec le serveur (4 pour Netscape) augmente d autant la saturation du réseau Le protocole HTTP - HTTP/0.9 - Lacunes et limitations - Client, serveur et intermédiaires Il peut y avoir plusieurs intermédiaires... Serveur (origin server) Intermédiaire (proxie, gateway, tunnel) Client (user agent) Cache Cache Si on peut efficacement gérer les caches on optimise la charge du réseau on améliore le confort de l utilisateur Le protocole HTTP - HTTP/0.9 - Lacunes et limitations -
Soumission de formulaires Nécessité d un échange bidirectionnel Nom : Prénom : GET POST Option TIC? : Oui Non Réponse du serveur Serveur Le client doit pouvoir envoyer au serveur des données fournies par l utilisateur Le protocole HTTP - HTTP/0.9 - Lacunes et limitations - Statut de la réponse > telnet www.ec-lyon.fr 80 GET http://www.ec-lyon.fr/tagada.html <HTML> <HEAD> <TITLE> 404 Not Found </TITLE> </HEAD> <BODY> Nous sommes désolés, mais le document que vous avez demandé n existe pas sur ce serveur! </BODY> </HTML> Connection closed by foreign host > En cas d erreur, l utilisateur est prévenu, mais pas le client! Le protocole HTTP - HTTP/0.9 - Lacunes et limitations -
Le protocole HTTP HTTP/1.0 - Introduction - - Forme de la requête - - Forme de la réponse - - Gestion des caches - - Authentification - - Evolutions - Le protocole HTTP RFC 1945 : HTTP/1.0 Mai 1996 : la RFC 1945 spécifie le protocole HTTP/1.0 la version précédente est appelée HTTP/0.9 3 méthodes : GET, HEAD, POST Des messages (requête et réponse) avec une entête (métainformations) et un corps (information) Des directives spécifiques pour la gestion des caches Une réponse comportant obligatoirement une info de statut Des directives pour l identification du client et du serveur Un mécanisme d authentification (user, password) N.B. La RFC 1945 est informationnelle (i.e. elle ne vise pas à définir un standard) Le protocole HTTP - HTTP/1.0 - Introduction -
Exemple de session HTTP/1.0 > telnet www.ec-lyon.fr 80 GET http://www.ec-lyon.fr/index.html HTTP/1.0 User-Agent: Mozilla/4.03 [fr] HTTP/1.0 200 Ok Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 Content-Type: text/html <HTML> </HTML> Connection closed by foreign host > N.B. Les lignes sont délimitées par des CRLF Remarquer les lignes vides permettant de délimiter la fin de la requête et de l entête de la réponse Le protocole HTTP - HTTP/1.0 - Introduction - Le protocole HTTP HTTP/1.0 - Forme de la requête - Le protocole HTTP
Forme de la requête GET http://www.ec-lyon.fr/index.html HTTP/1.0 Méthode (GET, HEAD ou POST) URI de la ressource (en fait, URL - relative ou absolue) version HTTP du client (HTTP/1.0) Méthodes : GET : le client récupère la ressource spécifiée par l URI HEAD : le client récupère l entête de la ressource (gestion des caches) POST : le client envoie des données à la ressource spécifiée par l URI. Cette ressource est en général une procédure qui traite les données et renvoie un compte-rendu d exécution sous la forme d un document html Le protocole HTTP - HTTP/1.0 - Requête - URLs relatives et serveurs virtuels telnet 156.18.19.2 80 GET /index.html HTTP/1.0 GET /index.html Serveur? http://www.ec-lyon.fr/index.html ou http://www2.ac-lyon.fr/index.html Dans le cas d une URL relative, sur une machine comportant des serveurs virtuels, il est impossible de savoir de quel document il s agit Solution : utiliser une URL absolue GET http://www.ec-lyon.fr/index.html HTTP/1.0 Le protocole HTTP - HTTP/1.0 - Requête -
Entêtes de la requête Il existe trois types d entêtes pour une requête Entête générique (concerne l échange, requête ou réponse) Entête de la requête (concerne la requête) Entête de l entité (méta-information, concerne les données) GET http://www.ec-lyon.fr/index.html HTTP/1.0 Date: Mon, 30 Aug 1999 12:54:39 GMT User-Agent: Mozilla/4.03 [en] Content-Length: 0 Le protocole HTTP - HTTP/1.0 - Requête - Entêtes - Entête générique Date: Mon, 30 Aug 1999 12:54:39 GMT Date : Date et heure du client - n a de sens qu avec POST - peu utilisé (optionnel) La date peut prendre trois formats différents : Date: Sun, 06 Nov 1994 08:49:37 GMT RFC 822/1123 Date: Sunday, 06-Nov-94 08:49:37 GMT RFC 850/1036 Date: Sun Nov 6 08:49:37 1994 asctime() ANSI C Clients et serveurs doivent reconnaître les trois formats, mais ne doivent générer que le premier Le protocole HTTP - HTTP/1.0 - Requête - Entêtes -
Entête de la requête From: webmaster@ec-lyon.fr Referer: http://www.ec-lyon.fr/index.html User-Agent: Mozilla/4.03 [en] (Win95; I) From : adresse email de l utilisateur qui contrôle le client - peut poser des problème de protection de la vie privée - utile surtout pour les robots - non utilisé par les clients courants Referer : URI de la ressource à l origine de la requête - en clair, URL de la page Web contenant le lien suivi - utile pour les statistiques du serveur (suivi de liens cassés) - utilisé par NS et MSIE User-Agent : identifie le client - utile pour adapter les documents renvoyés en fonction du client ou de sa version - exemples : User-Agent: Mozilla/4.03 [en] (Win95; I) User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) Le protocole HTTP - HTTP/1.0 - Requête - Entêtes - Entête de l entité Content-Type: text/html Content-Length: 2564 Content-Encoding: x-gzip Content-Type : identifie le type de l information (corps) - types courants: text/plain, text/html, image/gif, image/jpeg - types déposés à l IANA Content-Length : nombre d octets d information - obligatoire avec POST, inutile sinon Content-Encoding : utile si l information est compressée ou autrement codée - indique la méthode de codage et donc de décodage - types déposés à l IANA Le protocole HTTP - HTTP/1.0 - Requête - Entêtes -
Corps de l entité Dans le cas d une requête, seule la méthode POST peut donner lieu à une entité avec un corps. Dans ce cas, la directive Content-Length est obligatoire. POST http://www.ec-lyon.fr/cgi-bin/test HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 34 NOM=Deubaze&PRENOM=Raymond&TIC=Oui Nom : Deubaze Prénom : Raymond Option TIC? Oui Non Le protocole HTTP - HTTP/1.0 - Requête - Le protocole HTTP HTTP/1.0 - Forme de la réponse - Le protocole HTTP
Forme de la réponse HTTP/1.1 200 Ok Version HTTP du serveur (1.x avec x maximum) Statut de la réponse (code numérique) Statut de la réponse (texte en clair) Codes statut : 1xx (Informational) : non utilisé, réservé pour des applications futures 2xx (Success) : requête correctement reçue, comprise, traitée 3xx (Redirection) : Il faut une autre requête pour accéder à la ressource 4xx (Client Error) : requête syntaxiquement incorrecte ou incomprise 5xx (Server Error) : requête correcte mais non satisfaite Le protocole HTTP - HTTP/1.0 - Réponse - Statuts 2xx (Success) HTTP/1.1 200 Ok HTTP/1.1 201 Created HTTP/1.1 202 Accepted HTTP/1.1 204 No Content 200 : requête satisfaite 201 : une URI a été créée - cf. corps et directive Location pour plus d info 202 : requête acceptée mais non traitée - cf. corps pour plus d info 204 : requête satisfaite - le serveur n a rien de plus à dire - pas de corps - l écran présenté à l utilisateur ne devrait pas être modifié par le client Le protocole HTTP - HTTP/1.0 - Réponse - Statuts -
Statuts 3xx (Redirection) HTTP/1.1 300 Multiple Choices HTTP/1.1 301 Moved Permanently HTTP/1.1 302 Moved Temporarily 300 : la ressource demandée existe sous plusieurs formes - cf. corps et autres directives pour plus d info - exemple : on demande index.html et le serveur dispose de index.html.fr et de index.html.en 301 : la ressource a changé d adresse - cf. directive Location 302 : la ressource existe mais est temporairement inaccessible - cf. directive Location et corps pour une alternative présentée à l utilisateur (pas de redirection automatique) Le protocole HTTP - HTTP/1.0 - Réponse - Statuts - Statuts 4xx (Client Error) HTTP/1.1 400 (Bad Request) HTTP/1.1 401 (Unauthorized) HTTP/1.1 403 (Forbidden) HTTP/1.1 404 (Not Found) 400 : requête syntaxiquement incorrecte 401 : la ressource nécessite une authentification de l utilisateur. La réponse comporte forcément une directive WWW-Authenticate pour permettre une autre requête avec la directive Authorization. 403 : le serveur refuse de délivrer la ressource et il ne s agit pas d un problème d authentification 404 : ressource inexistante (faute de frappe dans l URL ou document supprimé) Le protocole HTTP - HTTP/1.0 - Réponse - Statuts -
Statuts 5xx (Server Error) HTTP/1.1 500 (Internal Server Error) HTTP/1.1 501 (Not Implemented) HTTP/1.1 502 (Bad Gateway) HTTP/1.1 503 (Service Unavailable) 500 : le serveur a eu un problème (cf. procedure core dump ou syntax error) 501 : le serveur est incapable d appliquer la requête 502 : le serveur est un proxie ou une passerelle, et a reçu une réponse erronée d une machine située en amont 503 : le serveur n est pas en mesure de satisfaire la requête à cause d'un problème temporaire (cf. surcharge ou maintenance). Ce code implique que le problème sera résolu dans un certain délai. Le protocole HTTP - HTTP/1.0 - Réponse - Statuts - Entêtes de la réponse Il existe trois types d entêtes pour une réponse Entête générique (concerne l échange, requête ou réponse) Entête de la réponse (concerne la réponse) Entête de l entité (méta-information, concerne les données) HTTP/1.0 200 Ok Date: Mon, 31 Aug 1999 17:10:18 GMT Pragma: no-cache Server: Microsoft-IIS/4.0 Content-Type: text/html Entêtes génériques Date : Date et heure du serveur - utilisé par les caches Pragma : no-cache - La réponse ne doit pas être cachée Le protocole HTTP - HTTP/1.0 - Réponse - Entêtes -
Entête de la réponse Location: http://www.ec-lyon.fr/sommaire.html.fr Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 WWW-Authenticate: Basic realm="gestion du serveur ECL" Location : URI absolue d une ressource - cf. statuts 3xx Server : Identification du serveur origine (attention, problème de sécurité ) WWW-Authenticate : demande d authentification de l utilisateur - cf. statut 401 (Authorization Required) Le protocole HTTP - HTTP/1.0 - Réponse - Entêtes - Entête de l entité Content-Type: text/html Content-Length: 2564 Content-Encoding: x-gzip Expires: Sat, 01 Jan 2000 00:00:01 GMT Last-Modified: Sun, 06 Nov 1994 08:49:37 GMT Content-Type : type de l information (corps) - types courants: text/plain, text/html, image/gif, image/jpeg - déposés à l IANA Content-Length : nombre d octets d information - obligatoire Content-Encoding : utile si l information est compressée ou codée - on en déduit la méthode de décodage - types déposés à l IANA Expires : limite de validité de la ressource - utilisé par les caches Last-Modified : date et heure de dernière modification de la ressource - cf. caches pour une éventuelle mise à jour de la version cachée Le protocole HTTP - HTTP/1.0 - Réponse - Entêtes -
Corps de l entité HTTP/1.0 200 Ok Content-Type: text/html Content-Length : 89 <HTML> <HEAD><TITLE> My first try </TITLE></HEAD> <BODY>Hello World!</BODY> </HTML> Une réponse comporte en général une entité avec un corps, dans ce cas, la directive Content-Length est obligatoire. Seules les réponses à une requête avec la méthode HEAD comportent systématiquement une entité dépourvue de corps. Certaines réponses avec des statuts particuliers (par exemple 401 Authorization Required) sont également dépourvues de corps. Le protocole HTTP - HTTP/1.0 - Réponse - Le protocole HTTP HTTP/1.0 - Gestion des caches - Le protocole HTTP
Gestion des caches Client Proxie Passerelle Serveur Cache Cache Cache Validité de la copie cachée? HTTP/1.0 dispose de mécanismes qui permettent de faciliter la gestion des caches. Ces mécanismes comprennent : la méthode HEAD une directive de GET conditionnel : If-Modified-Since (dans l'entête de la requête) des directives permettant de déterminer la durée de cachabilité d une information : Date (entête générique), Expires, Last-Modified (entête de l entité) Le protocole HTTP - HTTP/1.0 - Gestion des caches - La directive Expires Client Proxie Serveur Cache Cache Validité de la copie cachée? Lorsqu un intermédiaire reçoit une requête, il effectue les opérations suivantes : La ressource est-elle cachée? non : on envoie un GET au serveur, on cache la réponse, on fait suivre au client oui - La ressource cachée est-elle périmée? (Expires, ou algorithme cache) non : on envoie au client Il faut vérifier si la version cachée est la bonne. Si oui, on l envoie au client, si non on met à jour le cache puis on envoie au client. Le protocole HTTP - HTTP/1.0 - Gestion des caches -
1. La méthode HEAD HEAD http://www.ec-lyon.fr/index.html HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 01 Sep 1999 10:48:35 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 Last-Modified: Tue, 06 Jul 1999 15:06:08 GMT Content-Length: 5953 Content-Type: text/html L envoi d une requête avec la méthode HEAD provoque une réponse dépourvue de corps, mais dont toutes les entêtes sont telles qu elles auraient été si la méthode avait été GET. Ce mécanisme permet de déterminer si la ressource existe et si elle a été modifiée depuis le dernier accès (cf. Content-Length, Last-Modified), sans charger le réseau en demandant l envoi du corps (cf. GET). Si le document a été modifié il faut refaire une requête GET. Le protocole HTTP - HTTP/1.0 - Gestion des caches - 2. GET conditionnel L envoi d une requête du type GET conditionnel (avec If-Modified-Since) permet de combiner l effet d un HEAD, éventuellement suivi par un GET : GET http://www.ec-lyon.fr/index.html HTTP/1.0 If-Modified-Since: Wed, 07 Jul 1999 00:00:01 GMT HTTP/1.1 304 Not Modified Date: Wed, 01 Sep 1999 12:05:52 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 Si la ressource a été modifiée depuis la date fournie par le client, la réponse est celle correspondant à un GET normal Si la ressource n a pas été modifiée depuis cette date, le serveur retourne un code 304 - Not Modified Le protocole HTTP - HTTP/1.0 - Gestion des caches -
Entité non cachable Si le serveur ne désire pas qu une réponse soit cachée, il peut soit inclure une directive Pragma: no-cache soit inclure une directive Expires dont la date précède ou égale la date courante spécifiée par la directive Date GET http://www.ec-lyon.fr/index.html HTTP/1.0 HTTP/1.0 200 Ok Date: Wed, 01 Sep 1999 12:05:52 GMT Expires: Wed, 01 Sep 1999 12:05:52 GMT Content-Type: text/html Content-Length : 89 Pragma: no-cache <HTML> <HEAD><TITLE> My first try </TITLE></HEAD> <BODY>Hello World!</BODY> </HTML> Le protocole HTTP - HTTP/1.0 - Gestion des caches - Le protocole HTTP HTTP/1.0 - Authentification - Le protocole HTTP
Demande d authentification Lorsque le serveur reçoit une requête concernant une ressource protégée, il renvoie un code statut 401 - Unauthorized comportant une directive WWW-Authenticate indiquant au client comment effectuer une demande d accréditation : GET http://www.ec-lyon.fr/vfmgr/ HTTP/1.0 HTTP/1.1 401 Authorization Required Date: Wed, 01 Sep 1999 12:34:32 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 WWW-Authenticate: Basic realm="gestion du serveur ECL" Content-Type: text/html Le client doit alors refaire une requête comportant une directive Authorization afin d accréditer l utilisateur à l aide du mécanisme mentionné. Le seul mécanisme initialement proposé par HTTP/1.0 est : Basic Le protocole HTTP - HTTP/1.0 - Authentification - Authentification GET http://www.ec-lyon.fr/vfmgr/ HTTP/1.0 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== L'exemple ci-dessus correspond à l'envoi du nom d'utilisateur "Aladdin" et du mot de passe "open sesame" au serveur. La série de caractères envoyés correspond au codage en base64 de la chaîne obtenue en concaténant le nom d'utilisateur avec le mot de passe séparés par un caractère ":" (douple-point) : code_base_64(user_id:password) Cette méthode d'authentification (Basic) n'est pas sûre du tout, puisque le mot de passe circule sur le réseau sous forme certes encodée, mais non cryptée. De plus, en supposant que le serveur accepte de renvoyer l'entité correspondant à la ressource requise, cette entité ne sera pas cryptée. Le protocole HTTP - HTTP/1.0 - Authentification -
Le protocole HTTP HTTP/1.0 - Evolutions - Le protocole HTTP Connection: Keep-Alive HTTP/1.0 ne résout pas le problème dû au fait qu il y a une connexion par document. Certaines implémentations ont tenté de résoudre ce problème à l aide d une directive nouvelle : Keep-Alive HEAD / HTTP/1.0 Connection: Keep-Alive Host: www.ec-lyon.fr Problème avec les intermédiaires qui ne comprennent pas cette directive HTTP/1.1 200 OK Date: Thu, 02 Sep 1999 09:31:07 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 Last-Modified: Tue, 06 Jul 1999 15:06:08 GMT Content-Length: 5953 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html Le protocole HTTP - HTTP/1.0 - Evolutions -
WWW-Authenticate: Digest La méthode d authentification Digest (RFC 2069, puis 2617 ) résout le problème de la méthode Basic. HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Provoque une nouvelle requête avec la directive : Authorization: Digest username="mufasa", realm="testrealm@host.com", uri="/dir/index.html", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41", response="e966c932a9242554e42c8ee200cec7f6", Le protocole HTTP - HTTP/1.0 - Evolutions - WWW-Authenticate: Digest Le champ response de la directive Authorization est calculé de la façon suivante : A1 = MD5(username:realm:password) A2 = MD5(method:digestURI) response = MD5(A1:nonce:A2) MD5 (RFC 1321 ) est un algorithme permettant d'encrypter les données sous la forme d'une chaîne de 128 octets (checksum), ensuite représentée sous la forme de 32 caractères hexadécimaux (les 128 bits sont représentés 4 par 4, des poids forts vers les poids faibles). A réception de cette chaîne, le serveur effectue le même calcul de son côté, avec les données spécifiées et le mot de passe de l'utilisateur (qui n'a jamais circulé en clair sur la ligne) et compare les deux chaînes. N.B. la chaîne nonce peut être unique pour chaque réponse du type 401 - Unauthorized Le protocole HTTP - HTTP/1.0 - Evolutions -
Le protocole HTTP HTTP/1.1 - Introduction - - Méthodes - - Gestion des caches - Le protocole HTTP RFC 2616 : HTTP/1.1 Janvier 1997 : la RFC 2068 spécifie le protocole HTTP/1.1 Juillet 1999 : la RFC 2616, frappe la 2068 d obsolescence en résolvant certains problèmes, en précisant si nécessaire les mécanismes effectivement implémentés et fonctionnels, et en rendant caduques certains des aspects peu utilisés. Ces RFC visent à définir un standard. HTTP/1.1 s attache à résoudre certains problèmes de HTTP/1.0 : connections multiples (1 par requête) problème des serveurs virtuels (URI absolue obligatoire en 1.0) caching au mieux primitif, sinon inexistant (méthodes de gestion des caches insuffisantes) Le protocole HTTP - HTTP/1.1 - Introduction -
Problème des connexions multiples En HTTP/1.1 la connexion reste ouverte par défaut. Avantages : Gain de temps (CPU) et de mémoire à tous les niveaux (client, intermédiaires, serveur) Plusieurs requêtes peuvent être envoyées avant que la réponse à la première ne soit revenue au client (pipelining) Le réseau est moins chargé (moins d ouvertures de connexions). HTTP limite à 2 les connexions ouvertes en parallèle entre un client et un serveur donné. La gestion des erreurs est facilitée, puisque la liaison entre le client et le serveur n est pas systématiquement coupée L utilisateur perçoit une réponse plus rapide Fermeture de la connexion : Connection : close (ou timeout) Le protocole HTTP - HTTP/1.1 - Introduction - Problème des serveurs virtuels La directive Host : Une requête HTTP/1.1 doit obligatoirement comporter cette directive. Sinon, le serveur doit renvoyer le statut 400 - Bad Request Implémentation possible par des clients ou serveurs HTTP/1.0 (de fait, cette directive a été utilisée bien avant la RFC HTTP/1.1) > telnet 156.18.19.5 80 GET http://www.ec-lyon.fr/index.html HTTP/1.1 HTTP/1.1 400 Bad Request > telnet 156.18.19.5 80 GET /index.html HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 Ok Le protocole HTTP - HTTP/1.1 - Introduction -
Transfer-Encoding : Chunked En HTTP/1.0, la directive Content-Length est optionnelle : la fin de certains messages est déterminée par la coupure de la connexion. Il n'est parfois pas possible (ou très difficile) pour le serveur de connaître la longueur de certains messages avant de les avoir transmis (cf. messages générés par des procédures) HTTP/1.1 propose une solution : GET http://www.ec-lyon.fr/index.html HTTP/1.1 HTTP/1.1 400 Bad Request Connection: close Transfer-Encoding: chunked Content-Type: text/html 138 <HTML><HEAD><TITLE>400 Bad Request</TITLE></HEAD><BODY> <H1>Bad Request</H1> </BODY></HTML> 0 Le protocole HTTP - HTTP/1.1 - Introduction - Le protocole HTTP HTTP/1.1 - Méthodes - Le protocole HTTP
Méthodes sûres et idempotentes HTTP/1.1 définit la notion de méthode sûre et idempotente. Une méthode est sûre, si l'utilisateur peut légitimement supposer qu'une requête utilisant cette méthode ne produira rien d'irréversible sur le serveur. Une méthode est idempotente si l'envoi répété d'une même requête utilisant cette méthode produit à chaque fois le même résultat. Par convention, HEAD et GET sont considérées être des méthodes sûres et idempotentes. Lorsque la ressource adressée est une procédure, elle doit uniquement servir à retrouver de l'information et ne doit pas avoir d'effets de bord (modification d'information)... pas toujours le cas... POST ne doit être considérée ni sûre ni idempotente. Typiquement utilisée pour envoyer au serveur le contenu d'un formulaire conduisant à modifier des données... Le protocole HTTP - HTTP/1.1 - Méthodes - La méthode OPTIONS La méthode OPTIONS permet de requérir des informations sur les options de communication disponibles tout au long de la chaîne allerretour identifiée par l'uri de la requête. Elle permet typiquement de connaître la configuration du serveur final et des intermédiaires. Cette méthode est sûre et idempotente. OPTIONS / HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 OK Date: Mon, 06 Sep 1999 08:02:56 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 Content-Length: 0 Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTION, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE Une réponse à une requête OPTIONS ne peut être cachée. Le protocole HTTP - HTTP/1.1 - Méthodes -
La méthode GET La méthode GET permet de requérir l'information, quelle qu'elle soit, identifiée par l'uri de la requête. Si cette URI correspond à une procédure, l'information n'est pas constituée par le contenu de la procédure, mais est le produit du résultat de son exécution. GET doit pouvoir être considérée comme sûre et idempotente. GET /index.html HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 Ok Si l'une des directives If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ou If-Range est présente, on parle de GET conditionnel. Si la directive Range est présente, on parle de GET partiel. Une réponse à une requête GET peut éventuellement être cachée dans la mesure ou les directives de gestion des caches le permettent. Le protocole HTTP - HTTP/1.1 - Méthodes - La méthode HEAD La méthode HEAD se rapproche de GET, sauf qu'on demande au serveur de ne transmettre que l'entête de l'entité demandée. Le corps de l'entité ne doit pas être transmis. HEAD doit pouvoir être considérée comme sûre et idempotente. HEAD /index.html HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 OK Date: Wed, 01 Sep 1999 10:48:35 GMT Last-Modified: Tue, 06 Jul 1999 15:06:08 GMT Content-Length: 5953 Content-Type: text/html Cette méthode est souvent utilisée pour obtenir des métainformations au sujet d'une entité, sans être obligé de la transmettre. Elle permet par exemple de tester la validité de liens hypertextes, ou celle d'une copie cachée. Une réponse à une requête HEAD peut éventuellement être cachée. Le protocole HTTP - HTTP/1.1 - Méthodes -
La méthode POST La méthode POST permet d'envoyer de l'information, généralement entrée par l'utilisateur, à une procédure identifiée par l'uri de la requête. (Usages typiques : annotation de ressources existantes, envoi de messages, de formulaires, édition de bases de données ) En général POST ne peut être considérée ni sûre ni idempotente. POST /cgi-bin/test HTTP/1.1 Host: www.ec-lyon.fr Content-Type: application/x-www-form-urlencoded Content-Length: 34 NOM=Deubaze&PRENOM=Raymond&TIC=Oui La réponse à une requête POST peut avoir un statut 200 - Ok, 204 - No Content (réponse sans corps), ou 201 - Created assorti d'une directive Location si une nouvelle ressource a été créée. La réponse ne doit pas être cachée, sauf si des directives de gestion des caches le permettent explicitement. Le protocole HTTP - HTTP/1.1 - Méthodes - La méthode PUT La méthode PUT permet d'envoyer au serveur une entité qui doit ensuite être accessible comme la ressource identifiée par l'uri de la requête. (Typiquement mise à jour distante d'un document html - publish) La méthode PUT n'est pas sûre, mais elle est idempotente. Si une ressource a été créée la réponse aura un statut 201 - Created, si la ressource existait préalablement et a été modifiée le statut peut être 200 - Ok ou 204 - No Content. La réponse ne doit pas être cachée. Si un cache possède une copie de la ressource identifiée par l'uri de la requête, celle-ci doit être considérée comme périmée. Le protocole HTTP - HTTP/1.1 - Méthodes -
La méthode DELETE La méthode DELETE permet de demander au serveur de supprimer la ressource identifiée par l'uri de la requête. La ressource peut effectivement être détruite, ou simplement rendue inaccessible. Ceci dépend du serveur. La méthode DELETE n'est pas sûre, mais elle est idempotente. DELETE /essai/index.html HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 403 Forbidden Si la ressource a été supprimée immédiatement, la réponse aura un statut 200 - Ok, si la demande a été prise en compte, le statut peut être 202 - Accepted ou 204 - No Content. La réponse ne doit pas être cachée.si un cache possède une copie de la ressource identifiée par l'uri de la requête, celle-ci doit être considérée comme périmée. Le protocole HTTP - HTTP/1.1 - Méthodes - La méthode TRACE La méthode TRACE permet de déterminer sous quelle forme le serveur final reçoit une requête. La demande peut s'adresser à un intermédiaire si elle est assortie d'une directive Max-Forwards. La méthode TRACE est sûre et idempotente. TRACE / HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: message/http 2a TRACE / HTTP/1.1 Host: www.ec-lyon.fr 0 La réponse devrait toujours avoir un statut 200 - Ok, avec le corps de l'entité qui reflète exactement la requête telle que reçue par le serveur. La réponse ne doit pas être cachée. Le protocole HTTP - HTTP/1.1 - Méthodes -
Méthodes conditionelles Les directives If-Modified-Since, If-Unmodified-Since, If- Match, If-None-Match ou If-Range permettent de rendre une méthode conditionnelle. L'utilité d'effectuer des requêtes GET conditionnelles pour la mise à jour des caches a déjà été évoquée. Les directives If-Match et If-None-Match sont également particulièrement utiles avec les méthodes PUT et DELETE pour se garder des accès concurrents. La création d'une ressource est un cas particulier : PUT /tagada.html HTTP/1.1 Host: www.ec-lyon.fr If-None-Match: * Le protocole HTTP - HTTP/1.1 - Méthodes - Le protocole HTTP HTTP/1.1 - Gestion des caches - Le protocole HTTP
Entités partielles La directive Range permet à un client de demander une partie seulement d'une entité. Cette directive est utile dans le cas de documents très gros, par exemple en vue d'un affichage page par page, ou après une coupure de ligne accidentelle. GET /sh_ecl-bienvenue.gif HTTP/1.1 Host: www.ec-lyon.fr Range: bytes=0-1000 Le protocole HTTP - HTTP/1.1 - Gestion des caches - Entités partielles La réponse du serveur à une requête d'entité partielle comporte une directive Content-Range : HTTP/1.1 206 Partial Content Last-Modified: Thu, 13 Mar 1997 10:54:45 GMT Accept-Ranges: bytes Content-Length: 1001 Content-Range: bytes 0-1000/44320 Content-Type: image/gif GIF89a Ùçïïé Ÿ³³»» ±Ãà ÇǺËË ÏÏÄÓÓÈ ÍÛÛÑßßÖã... Content-Range précise la taille de l'extrait envoyé au client, sa position au sein de l'entité, ainsi que la taille de l'entité complète. Une directive Content-Length indique la taille de l'extrait transmis. Le protocole HTTP - HTTP/1.1 - Gestion des caches -
Entités partielles Lorsqu'un client dispose d'une entité partielle dans son cache, et qu'il désire la récupérer en entier : Il demande les parties manquantes de l'entité à l'aide d'un GET conditionnel assorti d'une directive If-Unmodified-Since ou If-Match Si le document a été modifié, il doit ensuite refaire une requête pour la récupérer en entier La directive If-Range effectue ce travail en une seule opération : GET /sh_ecl-bienvenue.gif HTTP/1.1 Host: www.ec-lyon.fr Range: bytes=1001- If-Range: Thu, 13 Mar 1997 10:54:45 GMT If-Range signifie : si l'entité a été modifiée, alors il me la faut en entier, sinon je me contenterai de l'extrait spécifié Le protocole HTTP - HTTP/1.1 - Gestion des caches - Validation d'une entité cachée HTTP/1.0 permet de valider une entité cachée à l'aide d'une date (cf. directives Last-Modified, If-Modified-Since). Ceci est parfois insuffisant (résolution = 1s), et la date de dernière modification est parfois très difficile à déterminer pour le serveur (cf. documents construits à la volée à partir d'extraits de bases de données). HTTP/1.1 propose un autre mécanisme, basé sur l'envoi par le serveur d'un identifiant unique, pour chaque entité d'une ressource donnée. Cet identifiant pourrait être obtenu en incrémentant un compteur à chaque fois qu'un document est modifié, ou en calculant sa checksum MD5. HEAD / HTTP/1.1 Host: www.ec-lyon.fr HTTP/1.1 200 OK Last-Modified: Tue, 06 Jul 1999 15:06:08 GMT ETag: "40799-1741-37821b60" Content-Length: 5953 Content-Type: text/html Le protocole HTTP - HTTP/1.1 - Gestion des caches -
Validation d'une entité cachée Une requête du type GET rendu conditionnelle avec If-None-Match permet d'obtenir un effet similaire à celui obtenu avec If-Modified-Since pour récupérer une ressource qui aurait été modifiée : GET /index.html HTTP/1.1 Host: www.ec-lyon.fr If-None-Match: "40799-1741-37821b60" HTTP/1.1 304 Not Modified Date: Mon, 06 Sep 1999 15:55:57 GMT Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9 ETag: "40799-1741-37821b60" If-None-Match peut être utilisée en conjonction avec If-Modfied-Since, qui s'interprète alors comme : à moins que la ressource n'ait été modifiée depuis... Le protocole HTTP - HTTP/1.1 - Gestion des caches - La directive Cache-Control HTTP/1.1 introduit la notion de caches partagé / privé et permet une gestion beaucoup plus fine de la cachabilité d'une entité et de la date d'expiration d'une copie cachée. La directive Cache-Control précise quel doit être le comportement des caches. Cette directive générique peut être associée à une requête ou à une réponse. Elle doit être transmise tout au long de la chaîne des intermédiaires sans être modifiée par aucun d'eux, puisqu'elle s'adresse à tous les éléments de cette chaîne disposant d'un cache. Le protocole HTTP - HTTP/1.1 - Gestion des caches -
Cachabilité d'une entité Cache-Control: public Cache-Control: private Cache-Control: no-cache Cache-Control: no-store public : l'entité peut être cachée. Permet par exemple d'autoriser la mise en cache de la réponse à une requête POST private : l'entité ne peut être cachée que par un cache privé, c'est à dire celui du poste de travail de l'utilisateur final. no-cache : l'entité ne doit pas être cachée. no-store : l'entité ne doit pas être stockée en mémoire non volatile (cf. disque dur, bande de sauvegarde ) Le protocole HTTP - HTTP/1.1 - Gestion des caches - Date d'expiration Cache-Control: public, max-age=864000, s-maxage=432000 Cache-Control: must-revalidate Expires: Mon, 06 Sep 1999 15:55:57 GMT max-age : l'entité peut être cachée. Lorsque son âge aura dépassé la durée spécifiée (864000 secondes = 10 jours), elle devra être considérée comme périmée. s-maxage : l'entité peut être cachée. Lorsque son âge aura dépassé la durée spécifiée (432000 secondes = 5 jours), un cache partagé devra la considérer comme périmée. must-revalidate : il est interdit de délivrer une copie périmée. Expires : indique la date limite de consommation d'une entité. Le protocole HTTP - HTTP/1.1 - Gestion des caches -
Non-respect de la date d'expiration Cache-Control: max-age=3600 Cache-Control: min-fresh=7200 Cache-Control: max-stale=86400 Cache-Control: only-if-cached max-age : le client n'acceptera pas une entité cachée pendant plus de la durée spécifiée (3600 secondes = 1h) min-fresh : le client désire une entité dont la durée de validité est encore au moins égale à la durée spécifiée (7200 secondes = 2h) max-stale : le client accepte une entité périmée, à condition qu'elle ne le soit pas depuis plus de la durée spécifiée (86400 secondes = 1 jour) only-if-cached : le client ne désire l'entité que si elle est cachée (utile en cas de forte congestion du réseau) Le protocole HTTP - HTTP/1.1 - Gestion des caches - La directive Warning Warning: 110 www.ec-lyon.fr "Response is stale" Warning: 111 www.ec-lyon.fr "Revalidation failed" Warning: 112 www.ec-lyon.fr "Disconnected operation" La directive Warning permet de donner des informations supplémentaires, qui n'apparaîtraient pas autrement dans le message. 110 - Response is stale : doit impérativement être précisé à chaque fois qu'un intermédiaire envoie une copie périmée à un client (même si celuici l'a demandé) 111 - Revalidation failed : l'intermédiaire a cherché à rafraîchir sa copie, mais n'a pas réussi (serveur inaccessible) 112 - Disconnected operation : l'intermédiaire est temporairement déconnecté du réseau et ne peut rafraîchir sa copie Le protocole HTTP - HTTP/1.1 - Gestion des caches -
Références World-Wide Web: The information Universe, Tim Berners-Lee, Robert Cailliau et al., Feb 1992. The original HTTP as defined in 1991, Tim Berners-Lee RFC 1123 - Requirements for Internet Hosts -- Application and Support, R. Braden, Octobre1989 RFC 1321 - The MD5 Message-Digest Algorithm, R. Rivest, Avril 1992 RFC 1945 - HTTP/1.0 - Hypertext Transfer Protocol, Tim Berners-Lee et al., Mai 1996 RFC 2616 - HTTP/1.1 - Hypertext Transfer Protocol, Roy Fielding et al., Juin 1999 RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication, J. Franks et al., Juin 1999 Le protocole HTTP