Vous êtes sur la page 1sur 45

HTTP : le protocole du Web pass en revue

par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)
Date de publication : 26/07/2009 Dernire mise jour : 11/09/2009

HTTP est le protocole du Web. Comprendre HTTP, c'est comprendre une bonne partie du fonctionnement du Web et une partie consquente des enjeux d'aujourd'hui concernant la scurit des applications webs. Nous allons dtailler dans cet article le protocole en luimme. Vous allez voir qu'il n'est pas spcialement simple, contrairement ce qu'on pourrait penser, et qu'une mauvaise comprhension ou utilisation peuvent avoir des repercussions nfastes, notamment sur les performances, le rendu final de la rponse, voire la scurit du rseau. Nous nous rendrons aussi compte qu'il est complet, et qu' ce titre on utilise rarement son plein potenciel, tort (mme si quelques fonctionnalits sont tout de mme trs spcifiques). Cet article est publi, mais toujours en cours de conception. La date de mise jour indique la version.

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

I - Prambule............................................................................................................................................................... 4 II - Introduction HTTP...............................................................................................................................................5 II-A - Dfinitions......................................................................................................................................................5 II-B - Historique...................................................................................................................................................... 6 II-C - Diffrence entre les versions........................................................................................................................ 6 II-C-1 - HTTP 0.9.............................................................................................................................................. 6 II-C-2 - HTTP 1.0.............................................................................................................................................. 6 II-C-3 - HTTP 1.1.............................................................................................................................................. 7 III - Requtes............................................................................................................................................................... 8 III-A - Typographie..................................................................................................................................................8 III-B - Les mthodes...............................................................................................................................................9 III-B-1 - GET......................................................................................................................................................9 III-B-2 - HEAD................................................................................................................................................. 10 III-B-3 - POST................................................................................................................................................. 11 III-B-4 - PUT....................................................................................................................................................12 III-B-5 - DELETE............................................................................................................................................. 12 III-B-6 - OPTIONS...........................................................................................................................................13 III-B-7 - TRACE...............................................................................................................................................13 III-B-8 - CONNECT......................................................................................................................................... 13 IV - Rponses............................................................................................................................................................ 15 IV-A - Typographie............................................................................................................................................... 15 IV-B - Codes de retour.........................................................................................................................................15 IV-B-1 - Codes 1xx - Informations..................................................................................................................16 IV-B-1-a - 100 - Continue..........................................................................................................................16 IV-B-1-b - 101 - Switching Protocols.........................................................................................................16 IV-B-2 - Codes 2xx - Succs..........................................................................................................................17 IV-B-2-a - 200 - OK...................................................................................................................................17 IV-B-2-b - 201 - Created........................................................................................................................... 17 IV-B-2-c - 202 - Accepted......................................................................................................................... 17 IV-B-2-d - 203 - Non-Authoritative Information......................................................................................... 18 IV-B-2-e - 204 - No Content......................................................................................................................18 IV-B-2-f - 205 - Reset Content..................................................................................................................18 IV-B-2-g - 206 - Partial Content................................................................................................................ 18 IV-B-3 - Codes 3xx - Redirection................................................................................................................... 19 IV-B-3-a - 300 - Multiple Choices............................................................................................................. 19 IV-B-3-b - 301 - Permanently Redirect..................................................................................................... 20 IV-B-3-c - 302 - Found.............................................................................................................................. 20 IV-B-3-d - 303 - See Other....................................................................................................................... 20 IV-B-3-e - 304 - Not Modified....................................................................................................................21 IV-B-3-f - 305 - Use Proxy........................................................................................................................ 21 IV-B-3-g - 306 inusit................................................................................................................................ 21 IV-B-3-h - 307 - Temporary Redirect.........................................................................................................21 IV-B-4 - Codes 4xx - Erreurs client................................................................................................................ 22 IV-B-5 - Codes 5xx - Erreurs serveur............................................................................................................ 22 V - Les en-ttes......................................................................................................................................................... 23 V-A - Gnraux.................................................................................................................................................... 23 V-B - D'entit........................................................................................................................................................ 23 V-C - De requte..................................................................................................................................................23 V-D - De rponse................................................................................................................................................. 23 VI - Transactions partielles........................................................................................................................................ 24 VII - Proxies............................................................................................................................................................... 26 VII-A - Dfinitions................................................................................................................................................. 26 VII-B - Rles......................................................................................................................................................... 27 VII-C - La mise en place sur les clients.............................................................................................................. 28 VII-D - Exemple pratique......................................................................................................................................29 VIII - Le cache........................................................................................................................................................... 31 VIII-A - Dfinitions................................................................................................................................................ 31 VIII-B - Le fonctionnement................................................................................................................................... 32
-2Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

VIII-B-1 - Au coeur du mcanisme de cache de HTTP 1.0........................................................................... 33 VIII-B-2 - Au coeur du mcanisme de cache de HTTP 1.1........................................................................... 34 VIII-B-3 - Fraicheur des donnes, validations et requtes partielles..............................................................35 VIII-B-4 - Provoquer le cache ou l'viter........................................................................................................ 36 IX - L'authentification................................................................................................................................................. 38 X - Ngociation de contenu.......................................................................................................................................39 XI - Gestion des connexions TCP avec HTTP......................................................................................................... 40 XI-A - Connexions parallles............................................................................................................................... 40 XI-B - Connexions persistantes............................................................................................................................40 XI-C - Pipelining................................................................................................................................................... 41 XII - Les outils............................................................................................................................................................42 XII-A - Les langages Web : PHP......................................................................................................................... 42 XII-B - Telnet.........................................................................................................................................................42 XII-C - Wget..........................................................................................................................................................42 XII-D - Curl........................................................................................................................................................... 43 XII-E - Outils webs............................................................................................................................................... 43 XIII - Au del du Web avec HTTP............................................................................................................................ 44 XIV - Rfrences....................................................................................................................................................... 45

-3Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

I - Prambule
HTTP est l'HyperText Transfert Protocol : le protocole servant vhiculer les pages web de l'Internet. Le plus souvent -mme si ce n'est qu'un dtail- les exemples de syntaxe HTTP de cet article seront simplifis. Un exemple visant dmontrer l'utilisation de tel procd ne montrera que du code le concernant, faisant l'impasse sur certains en-ttes importants pourtant prsents dans les rponses relles. Ceci est dans un but de concision et de clart, en effet une transaction HTTP est souvent reprsente par un flux d'informations (en-ttes) assez consquent. Certains en-ttes peuvent contenir des valeurs invalides, particulirement "Content-Length" sens reprsent le poids du message en octets. Si le lecteur s'amuse compter le poids rel : je ne l'ai pas calcul tout le temps et ai mis souvent des valeurs arbitraires se rapprochant de la valeur relle (le tutoriel n'est pas crit partir d'un exemple prcis et concrt, mais de multiples exemples). Cet article n'a pas vocation tre exhaustif, ni mme exempt de maladresses (mme si son auteur a rellement exerc un travail de recherche approfondi). Non, ce n'est pas la norme complte de HTTP en Franais ;-) Vraiment, je vous renvoie aux RFCs (Request For Comment) qui reprsentent les vraies normes (que l'on appelle plutt "recommendations") et dont les liens vous serons plusieurs fois suggrs. Ces RFCs sont techniques, et leur exhaustivit laisse quelque fois dsirer. En fait elles sont claires et comprhensibles, mais elles laissent quelques fois des flous, la plupart du temps volontaires ("les serveurs pourront alors -s'ils le souhaitent- faire ceci et cel" "Soient 3 problmes A B C se rapportant un thme commun, A et B sont trs nettement dtaills mais on parle peine de C", "Le client dcidera alors ((aucun critre nonc)) si oui ou non tel ou tel vnement"... ). Les bases de cet article sont les RFCs cits, ainsi que des ouvrages : HTTP Developer' Handbook , de Chris Shiflett et HTTP: The Definitive Guide des ditions O'Reilly. Bien entendu, de nombreuses exprimentations ont t tentes pendant la rdaction de cet article. Apache est le serveur choisi, les clients sont divers : PHP, Curl, Telnet, Firefox 3... Notez aussi que parler du "protocole HTTP" est une bizarrerie de langue. Le "P" de HTTP signifiant "Protocol", on devrait plutt dire "le HTTP", plutt que "le protocole HTTP". Mais cette appelation sera tout de mme retenue dans l'article, car elle est devenue commune dans toutes les bouches et tous les textes, elle est admise de tous.

-4Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

II - Introduction HTTP
HTTP est un protocole qui a t travaill par de nombreuses personnes partir de la fin des annes 80. En sont sorties des recommandations sous forme de RFC dont la plus importante est la RFC2616, elle dfinit le HTTP1.1 actuel. Beaucoup d'autres RFCs entrent en jeu cependant dans le fonctionnement de HTTP, comme la 2617 qui dcrit les processus d'authentification, ou encore la 2109 qui dcrit les mcanismes de persitance. Chaque serveur ou client Web est tenu de l'implmenter au plus juste, et comme la recommandation laisse quelque fois des "blancs", il existe des disparits entre les logiciels l'utilisant (clients et serveurs). Par disparit, on pourra citer le non respect des recommandations (carrment, mais a devient de plus en plus rare), un respect partiel, ou encore un fonctionnement propre non dcrit dans les recommandations. Les serveurs sont plutt "bons", c'est dire qu'ils implmentent tous un protocole HTTP acceptable et compatible peu prs partout, pour peu qu'ils ne datent pas d'il y a 10 ans. Heureusement, les vieux serveurs sont rares de nos jours sur Internet. Cot navigateurs, il faut qu'il soient rcents. Les navigateurs modernes sont corrects, les vieux ont des problmes avec HTTP de diffrents ordres : cache mal gr, compression de donnes mal ou pas supporte, en-tte ignors... Quoiqu'il en soit, cela reprsente une trs maigre partie des clients HTTP d'aujourd'hui, il faudra par contre prter attention aux clients logs dans des appareils portatifs (tlphones portables, PDAs...) car il est possible qu'ils ne respectent pas totalement HTTP non plus, soit du fait de leur relative jeunesse, soit par dcision des constructeurs. Quoiqu'il en soit il n'y a pas d'inquitude particulire avoir, il est dans l'intert de tout le monde de respecter les recommandations de HTTP, et HTTP fonctionne bien de nos jours sur le Web, la preuve ? Et bien c'est le Web tout simplement ! La RFC2616 dcrit le fonctionnement global de HTTP, certains points particuliers sont dcrits plus prcisment dans d'autres RFCs. RFC2617, par exemple, explique comment fonctionnent les processus d'authentification de HTTP La gestion de la persistance, elle, est dtaille dans la RFC 2109.

II-A - Dfinitions
HTTP est un protocole applicatif log sur la couche 7 du modle OSI (ou 4 du modle simplifi), soit : tout en haut. Il ne faut donc pas considrer HTTP comme un "protocole rseau", car il n'a que faire du rseau proprement parl : les mots IP, paquet, tat ou encore synchronisation ne lui disent rien. HTTP est log (le plus souvent, donc on l'admettra) au dessus de TCP, lui mme log dans IP, au dessus de la couche physique rseau. Le rle de HTTP est d'assurer le transport d'informations relatives aux changes ports sur le contenu Web. Ainsi, HTTP ne "se connecte" pas d'une machine l'autre : c'est dja fait par les couches du dessous, par dfaut sur le port TCP 80, qui est reserv l'usage d'HTTP HTTP n'est pas crypt (HTTPS l'est), donc n'importe que peut lire HTTP, et peut mme l'crire, du moment qu'il respecte sa syntaxe et ses recommandations. HTTP est une des parties du Web. Les 2 autres sont URI et HTML. Je ne prsente pas HTML (je ne pense pas que ce soit ncessaire), mais je vais claircir les termes URI et URL. Les URIs sont des moyens mmorisables par l'Homme d'identifier l'emplacement d'une information que l'on appelle ressource. C'est comme une adresse postale : une adresse web. Les URIs se dcomposent en 2 catgories, les URLs, et les URNs. Aujourd'hui, les URNs sont tellement rares que l'on admet la confusion URI = URL, mme si de manire stricte, cette galit n'est pas juste. Les URLs se dcomposent en plusieurs parties et ne peuvent contenir que des caractres de la table ASCII, les autres doivent tre encods. Les parties des URLs ainsi que sa forme gnrale telle que dfinie par la recommandation est <sheme>:// <user>:<password>@<host>:<port>/<path>;<params>.<query>#<fragment>. Les parties scheme et host sont obligatoires. Les URLs font donc partie de la dfinition du Web, qui ne se limite pas au seul protocole HTTP. Si l'URL possde une partie scheme gale "http", alors ce protocole entre en jeu. HTTP sert dans un premier temps changer des documents lisibles, encods en HTML. Bien sr, il peut aussi servir rappatrier des fichiers, mme si un protocole, FTP, est plus approri.

-5Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Pour distinguer le type des ressources changes, HTTP s'appuie sur MIME : Multipurpose Internet Mail Extensions. A la base prvu pour l'change d'Emails, MIME a t adopt pour l'change de documents webs. Maintenant que nous venons de dfinir brivement HTTP, URL, adresse, ressource et MIME nous allons pouvoir passer la suite. Les informations officielles sur les URIs se trouvent l'adresse http://www.w3.org/Addressing/ http:// Concernant MIME, la RFC2045 et ses soeurs sont la rfrence. Pour les types MIME, voyez www.iana.org/assignments/media-types/index.html

II-B - Historique
HTTP est n en 1989, en mme temps que le Web, principalement grce Sir Tim Berners Lee. Il m'est inutile de faire un historique, car celui-ci est disponible en ligne: Voyez www.w3.org/Consortium/history http://www.w3.org/History.html et http://

Quoiqu'il en soit, le dveloppement de HTTP est officiellement arrt aujourd'hui, mais l'

IETF, retravaille tout de http://

mme dessus depuis 2006 afin de l'amliorer et de le scuriser. HTTPBis sont des ides dcrites sur

tools.ietf.org/wg/httpbis/. Aussi, ds 1998, HTTP-NG tait dja dcrit, mais abandonn car trop prcoce pour l'poque. Tous les intrsss pourront donc lire les travaux et en apprendre un peu plus, je vous y insite ;-).

II-C - Diffrence entre les versions


Il existe 3 versions de HTTP ce jour. La version 0.9 n'est plus du tout supporte. La version 1.0 l'est partiellement : peu de navigateurs l'utilisent, mais la majorit des serveurs la prennent encore en charge. HTTP 1.1 est clairement la version utilise aujourd'hui, elle reprsente une trs large majorit des requtes HTTP mondiales.

II-C-1 - HTTP 0.9


Premire version de HTTP, apparue en 1990, elle n'est clairement plus supporte de nos jour. Ses caractristiques : 1 2 3 4 Seule la mthode GET existe : il est donc impossible d'envoyer des donnes vers les serveurs Il n'existe aucun type de fichier : seul le texte (text/plain) est gr Il n'existe aucun code de retour HTTP, si le document n'existe pas, une page blanche est servie De manire gnrale la notion d'en-tte HTTP n'est pas dfinie

Bref vous l'aurez compris, HTTP 0.9 est peine plus haut que TCP : la connexion s'tablit, le document, si trouv, est rappatri pour tre affich, et la connexion TCP est ferme, point final. C'est trs trs limit, d'ailleurs chose rigolote : interrogez Google avec HTTP 0.9 et voyez le rsultat ;-)

II-C-2 - HTTP 1.0


La version 1.0 a t normalise en 1996, mme si elle a commenc tre utilise avant. Elle dcrit le "vrai" Web que nous connaissons aujourd'hui, voyons cela : 1 2 3 Trs important : introduction de la mthode POST : le client peut envoyer des donnes vers le serveur qui executera alors un script CGI pour traiter ces donnes, apparaissent alors les formulaires, et l'interraction qui manquait au Web pour devenir le mdia incontournable que nous connaissons aujourd'hui D'autres mthodes HTTP font aussi leur apparition, nous ne manquerons pas de les dtailler, cependant seule HEAD est dcrite. PUT, LINK et UNLINK sont suggres seulement Avec cel arrive la gestion du tag <img> et la si importante notion d'en-ttes HTTP

-6Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

4 5 6 7

Aussi, arrive la gestion des types MIME : HTTP peut transporter des informations de diffrents types, qui seront traits chacun d'une manire diffrente par les 2 extrmits (serveur et client) On anticipe l'ampleur phnomnale qu'HTTP va prendre dans les communications Internet : HTTP 1.0 propose un mcanisme basique mais fonctionnel de gestion du cache et de la congestion du rseau La gestion de l'authentification est aussi intgre dans HTTP 1.0, avec 2 modes : basic ou digest Les connexions persistantes sont ajoutes, mais non utilises par dfaut par les clients et les serveurs

Comme nous le voyons, HTTP 1.0 est la base du Web que nous connaissons aujourd'hui, cette version du protocole est dfinie dans la RFC 1945 Notez que HTTP 1.0 ne propose aucun mcanisme de persistance applicative, il faudra attendre 1997 pour que Netscape en propose un : les cookies. La RFC 2109 dcrit le mcanisme.

II-C-3 - HTTP 1.1


En 1996, la part du Web dans l'Internet est dja considrable, mais l'Internet n'en est encore qu' ses balbuciements. De 1996 1999, le nombres de machines relies Internet va croitre sensiblement, et les experts anticipent alors le monde d'aujourd'hui : une trs grande partie de la plante est connecte, souvent au moyen de liaisons trs haut dbit et les "ordinateurs" ne sont plus les seules machines connectes : tlphones portables, netbooks, gadgets divers, rfrigrateurs ... HTTP 1.0 montre des limites en terme de cache, de gestion des connexions TCP, et des proxies. Il faut alors le moderniser et HTTP 1.1 arrive en 1999, entirement rtro-compatible avec HTTP 1.0 : Si un en-tte n'est pas compris par l'une des deux parties (client/serveur), il doit alors tre ignor. 1 2 3 4 5 6 7 8 9 10 Support de l'hebergement virtuel par nom : en-tte Host Prise en charge du relai bout--bout dans le transport de la version du protocole via proxies : en-tte Via Dcouverte de version : Mthode OPTION et en-tte Upgrade Prise en charge des requtes partielles : en-ttes Range et Content-Range Les connexions persistantes sont devenues les connexions par dfaut, en-tte Connection Prise en charge du pipelining (plusieurs requtes par connexion TCP), en-tte Content-Length et segmentation des rponses : chunked Amlioration dans la gestion du cache : Etags, Cache-Control, Age, max-age, If-None-Match ... Ajout du support de la ngociation de contenu, en-ttes Vary, Accept-* 24 nouveaux codes de rponse : 100, 206, 409... Amlioration de la compression avec une compression bout--bout, en-tte Transfert-Encoding

Comme on peut le constater, HTTP 1.1 est une relle volution, et nous ne manquerons pas de dtailler tous ces termes dans la suite de cet article. Il faut ce sujet savoir que la description de HTTP 1.1 est 3 fois plus grande que HTTP 1.0, le protocole se complxifie, s'largit, se divertit et parfois claircit des notions peu abordes, ou seulement suggres par HTTP 1.0, comme la ngociation de contenu.

-7Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

III - Requtes
Rappelons que nous sommes dans un environnement client/serveur. Un client va donc effectuer une requte vers un serveur, pour lui demander des informations. Celui-ci renvoie alors une rponse. A une requte correspond une et une seule rponse. Nous allons dans ce chapitre nous intresser la requte, donc la premire demi-partie d'une transaction. Il faut savoir que celui qui effectue la requte est appel 'client', c'est souvent un navigateur web ou une application web, mais pas tout le temps. Lorsque nous parlerons des proxies, nous verrons que ceux-ci sont la fois client et serveur.

III-A - Typographie
Une fois la connexion TCP tablie, le client envoie une requte HTTP, cela ressemble : Une requte HTTP
GET /en/html/dummy.php?page=dvp&article=http HTTP/1.1 Host: www.developper.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) FirePHP/0.2.4 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: rememberme=false;VAR=-120 {ventuel contenu de la requte ici}

Exemple hasardeux, dont voici la syntaxe: 1 2 3 4 Une, et une seule ligne de requte, sous la forme METHODE ressource http_version Zro ou plusieurs lignes dites d'en-ttes, sous la forme Titre-en-tte: valeur Eventuellement crlf (retour la ligne nouvelle ligne) Eventuellement du contenu, sur une ou plusieurs lignes, totallement spar des en-ttes

La ligne de requte et les en-ttes sont spars entre eux par le caractre <crlf> Mme si ce n'est pas recommand, pour des raisons historiques la plupart des machines acceptent juste <cr> ou juste <lf>, HTTP tant par nature assez permissif Tous les caractres connus de fin de ligne sont donc grs par HTTP, <crlf> tant le plus utilis. Les en-ttes sont spars du contenu par un <crlf> et le contenu est la seule partie facultative, sa prsence ou non dpend de la mthode utilise, dcrite dans la ligne de requte. Dans notre exemple, il n'y a pas de contenu : seules une ligne de requte et quelques lignes d'en-tte sont prsentes. Nous verrons que c'est une caractristique de la mthode GET. La ligne de requte d'une requte vers un proxy comporte l'URL complte et non juste la ressource demande sur le serveur. Les en-ttes doivent avoir la forme Titre: Valeur. Titre et Valeur doivent commencer par une majuscule, mais ils sont tout de mme accepts sans, mme si c'est un cas rare. Valeur peut reprsenter plusieurs valeurs intrinsques, elles seront alors espaces par des points-virgules. Les virgules, elles, sparent deux termes concernant la mme valeur. Par exemple : Exemple d'en-tte de requte HTTP
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3

-8Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Accept-Language: est le titre (ou l'intitul si vous prfrez), et fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 la valeur. Les parties de la valeur sont spares par des point-virgule, et compltes entre elles par des virgules. Rappel: HTTP indique que tout en-tte non compris (inexistant, mal orthographi...) doit tre ignor. Ainsi, les risques de "plantages" de HTTP sont maigres. La ligne de requte est obligatoire, c'est la premire ligne que le serveur va analyser, s'il ne la comprend pas, il ignorera tout le reste et renverra trs probablement une rponse d'erreur. La ligne de requte commence par la mthode HTTP, toujours crite en majuscules, suivie de la ressource demande, sous forme d'URI, puis la version du protocole HTTP utilise, aujourd'hui trs largement HTTP 1.1. Les lignes d'en-ttes se dcomposent en 4 groupes : gnriques, rponse, requte, et entit 1 2 3 4 Gnrique : dcrivent la transaction (requte ou rponse) HTTP en elle-mme Requte : dcrivent des caractristiques propres la requte HTTP Rponse : dcrivent des caractristiques propres la rponse HTTP Entit : dcrivent le contenu de la transaction (requte ou rponse) s'il est prsent Il faut noter qu'il n'y a pas d'ordre prcis dans l'apparition des en-ttes et qu'ils ne sont pas sensibles la casse, mme si la casse "majuscule en dbut de mot + minuscules" est souvent rencontre. Notez aussi que certains en-ttes sont obligatoires, d'autres non, nous verrons cel lorsque nous les passerons en revue.

III-B - Les mthodes


Toute ligne de requte commence par une mthode. Il existe dans HTTP 1.1 10 mthodes, et HTTP tant extensible, on peut tout fait rajouter des mthodes dans les serveurs et les clients. Les utilisateurs intrssrs se pencheront alors par exemple sur WebDAV. Parmi les 10 mthodes prsentes dans HTTP 1.1, deux - hrites de HTTP 1.0 - ont une spcification qui tient en 4 lignes (faon de parler), en consquence LINK et UNLINK sont trop floues et ne seront pas abordes ici. Chaque mthode HTTP a une smantique particulire, mais la majorit des navigateurs web d'aujourd'hui n'en comprennent que 2 ou 3: GET et POST (parfois CONNECT), ce qui est bien dommage. Les autres mthodes sont surtout utilises par les serveurs, qui communiquent entre eux via des languages webs (CGI) comme PHP ou PERL. Les services webs REST, par exemple, exploitent trs largement les potenciels de HTTP ainsi que toutes ses mthodes et beaucoup de codes de rponse. Le protocole applicatif ATOM joue aussi trs bien avec HTTP. Les serveurs, de manire native, comprennent presque toutes les mthodes. Apache2.2 comprend nativement GET,HEAD,POST et OPTIONS. Le support des autres mthodes se fait soit en rajoutant des modules, soit en les activant dans la configuration des modules prsents dans le binaire de la distribution. Dtaillons sans plus attendre ces mthodes. Sous Apache, les directives Limit, LimitExcept et TraceEnable permettent de grer les mthodes prises en charge par le serveur.

III-B-1 - GET
GET est la premire mthode qui a vu le jour. Elle indique au serveur que nous souhaitons obtenir une reprsentation de la ressource, en vue de la lire. De par sa nature, cette mthode suggre que la requte soit relativement concise, alors que la rponse, elle, peut tre trs lourde. En gnral, cette mthode dsquilibre la bande passante, le client envoyant trs peu de donnes, mais pouvant en recevoir en retour beaucoup (ceci n'est qu'une remarque ayant pour but de justifier qu'aujourd'hui, en grande majorit, un internaute possde une bande passante plus large en recption qu'en mission).
-9Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

C'est la mthode utilise par les navigateurs webs lorsqu'on entre une URL dans la barre d'adresse et qu'on la valide, ou encore lorsqu'on clique sur un lien dans une page web prsente en HTML. Cette mthode reprsente ainsi un trs large pourcentage du total de requtes web sur un serveur. Mme s'il est possible de passer des paramtres dans la requte, (appels "query string", les fameuses variables derrire le "?" spares par des "&"), GET ne doit jamais faire intervenir une modification de la ressource cot serveur. GET sert lire des donnes, pas en envoyer, ainsi une requte GET ne peut contenir de corps. Une requte GET peut tre mise en cache, elle ne doit contenir aucune information susceptible de varier dans le temps (du contenu par exemple). Aussi, un lien web (dont l'expression sera une requte HTTP de type GET) peut tre mis en favoris ou partag entre plusieurs personnes. exemple de requte GET
GET /imghp?hl=fr&tab=wi HTTP/1.1 Host: images.google.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729) FirePHP/0.2.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

Dans cet exemple, le client demande au serveur de lui servir une reprsentation de la ressource identifie par l'URI / imghp?hl=fr&tab=wi. Souvent, la rponse est en HTML, mais pas toujours : aujourd'hui le Web a chang par rapport aux dbuts de HTTP, et la rponse est aussi souvent du XML, du JSON, ou encore un format binaire comme de l'AMF On comprend bien pourquoi Google utilise une mthode GET pour son moteur de recherche : la requte peut tre identifie de manire unique, mise en favoris, mise en cache, sans jamais que le rsultat smantique ne change : elle ne comporte pas de corps. Il conviendra ainsi de faire attention la taille des donnes envoyes. GET ne permet que d'envoyer des donnes via l'URL, et notamment la Query String. En thorie, la limite est de 256 caractres, mais certains serveurs ou clients en acceptent plus, ou moins, Apache par exemple, accepte 1024 caractres. Une attention particulire devra tre apporte aux paramtres dans la Query String : ils ne doivent pas comporter d'informations sensibles telles que ?login=toto&password=developpez, car ces informations vont pouvoir tre mmorises par les caches (proxies), par le client (navigateur souvent), et vont mme pouvoir fuire via l'en-tte Referer dont nous reparlerons. GET est idempotente, si on execute plusieurs fois la mme requte, il se passe le mme rsultat sur le serveur.

III-B-2 - HEAD
HEAD est trs semblable GET, si bien que si l'on supporte l'un, en thorie on supporte l'autre (sauf cas trs rares). HEAD possde la mme signification que GET, la diffrence que la rponse ne comportera pas de corps. Seuls les en-ttes de la rponse seront envoys au client, sans le corps (souvent lourd) de celle-ci. C'est trs pratique pour tester une URL ou encore pour "pinger" un serveur HTTP, car la rponse sera trs lgre. On se sert de cette mthode en gnral pour tester l'existence d'une page (en analysant le code de rponse) : on n'a pas besoin du corps et de la reprsentation de la rponse, seuls les en-ttes nous importent. La rponse une requte HEAD sera exactement la mme qu' une requte GET, mais sans le corps. Les en-ttes seront identiques. exemple de requte HEAD
HEAD / HTTP/1.1 Host: google.com Keep-Alive: 300 Connection: keep-alive

- 10 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Comme on le voit, seuls les en-ttes de la rponse apparaissent, on connait donc les caractristiques de la rponse (son type, son poids, son encodage ...), mais on ne connait pas son contenu. Apache lie GET et HEAD : si vous dsactivez le support de l'un, l'autre sera aussi dsactiv

III-B-3 - POST
La mthode POST est utilise lorsque le client doit faire transiter un nombre consquent de donnes, vers un script sur le serveur qui va les traiter, ceci dans le but de crer ou mettre jour une ressource. Aujourd'hui, la seule manire pour un navigateur web d'envoyer du POST, est de le faire via un formulaire : une des grosses amliorations introduites par HTTP 1.1 par rapport HTTP 1.0. Javascript aussi est capable d'envoyer des requtes de type POST, mais ceci sort du cadre de cet article. Voici un exemple de requte POST : exemple de requte POST
POST /dossier/script.php HTTP/1.1 Host: developpez.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729) FirePHP/0.2.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Keep-Alive: 300 Connection: keep-alive nom=pauli&prenom=julien&data=some%20data

Voyez comme le corps de la requte nom=pauli&prenom=julien&data=some%20data est spar des en-ttes via une ligne blanche. Ici, les donnes sont donc transmises dans le corps de la requte, et non dans les en-ttes via le query string comme le suggrait GET. C'est bien l toute la diffrence. Ainsi, si le client demande rafraichir la page, le navigateur doit l'informer qu'il va retransmettre des donnes. POST est non idempotente, c'est dire que 2 requtes de ce type, strictement identiques, peuvent mener 2 traitement diffrents cot serveur; et c'est pour cela que le client n'a pas le droit de renvoyer une requte POST sans en avertir l'utilisateur.

Confirmation POST La diffrence fondamentale par rapport une mthode GET est que l'on est expressement invit envoyer des donnes en vue d'un traitement sur le serveur. Comme des donnes sont envoyes, la page de rponse est susceptible de varier en fonction de ces donnes d'entre, HTTP interdit ainsi de grer un quelconque cache d'une requte de type POST. Aussi, le client doit indiquer quel type de donnes il envoie, et la taille de celles-ci. Les en-ttes Content-Type et Content-Length sont donc ncessaires.

- 11 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

POST masque les donnes envoyes. L'URL ne contient pas (mais pourrait, ce n'est pas interdit) de query string, les donnes transitent dans le corps de la requte, mais elles n'en sont pas pour autant cryptes, invisibles, ou noninterceptables. Attention, POST n'est pas destine consulter une ressource, mais bien en crer une nouvelle ou mettre jour une existente. Les codes de rponse permettent de savoir comment la requte a t traite, un corps dans la rponse peut aussi afficher une page informant du dtail de la transaction.

III-B-4 - PUT
PUT est trs semblable POST. PUT permet au client de dposer des donnes vers une ressource sur le serveur, c'est en gros l'inverse de GET, qui demande une ressource. Il est utile de noter que souvent en PHP, on cherche envoyer des donnes via un "formulaire d'upload" ( RFC 1867) et le tableau $_FILES. Ce n'est pas tout fait correct niveau HTTP, souvent, utiliser PUT donne de bien meilleurs rsultats, et permet de passer outre les limitations du fichier php.ini, comme upload_max_filesize Apache ne gre pas nativement PUT, mais sa directive Script permet de l'intgrer. L'avantage de PUT est que le serveur est sens obir "btement" et dposer la ressource l'endroit voulu par le client (moyennant quelques mcanismes de scurit). Aucun script CGI n'est sens intervenir, je dis sens car Apache ne sait pas faire cel : il se repose sur un script CGI (comme PHP) pour grer PUT. exemple de requte PUT
PUT /data/julien/text/liste.txt HTTP/1.1 Host: developpez.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729) FirePHP/0.2.4 Content-Type: Text/plain Content-Length: 44 Bonjour, voici le contenu d'un fichier texte

Aujourd'hui encore, PUT est largement mconnue et sous-utilise, ce qui est trs dommage car ce n'est pas difficile mettre en place. PUT est idempotente, si on execute plusieurs fois la mme requte, il se passe le mme rsultat sur le serveur.

III-B-5 - DELETE
Son nom ne trompe pas, DELETE demande au serveur de supprimer une ressource, c'est un peu l'inverse de PUT. Attention, aucun mcanisme de scurit n'existe, et lorsque le serveur rpondra par "OK", ceci ne signifie pas que la ressource en question est supprime. Cel signifie que le serveur a compris votre requte, et va, dans un futur plus ou moins long, executer votre souhait. exemple de requte DELETE
DELETE /data/julien/text/liste.txt HTTP/1.1 Host: developpez.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729) FirePHP/0.2.4

Comme pour GET, une requte DELETE ne contient pas de corps. DELETE est idempotente, si on execute plusieurs fois la mme requte, il se passe le mme rsultat sur le serveur.

- 12 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

III-B-6 - OPTIONS
La mthode OPTIONS permet au client de demander au serveur ces capacits de prise en charge de HTTP. Si la requte prcise une ressource, alors la demande concerne celle-ci spcifiquement. Si au contraire la ressource indique est *, alors la requte concerne les capacits globales du serveur. exemple de requte OPTIONS
OPTIONS * HTTP/1.1 Host: developpez.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729) FirePHP/0.2.4

A cette requte, le serveur va rpondre grce un en-tte Allow, dans lequel il va placer en toutes lettres les mthodes HTTP qu'il gre (si celui-ci gre la mthode OPTIONS). Ce type de requte est extrmement pratique pour faire de la reconnaissance avant interrogation, elle permet un client de faire de la dcouverte en vue de ngocier des transactions futures.

III-B-7 - TRACE
Le but de cette mthode est assez particulier, et prcisons tout de suite qu'elle peut introduire des problmes de scurit. La mthode TRACE demande au serveur de renvoyer dans le corps de sa rponse, les en-ttes qu'il a reu dans sa requte. C'est un genre de "loopback", on envoie "ping" au serveur, qui doit rpondre par "ping". exemple de requte TRACE
TRACE /some/path/ressource.php HTTP/1.1 Host: developpez.com

Le corps de la rponse cette requte doit tre le contenu des en-tte de la requte elle-mme. Une requte TRACE ne comporte pas de corps. A quoi cela sert-il de rejouer la requte dans la rponse ? Et bien il faut se souvenir que des proxies, des passerelles ou encore des firewalls peuvent se loger entre le client et le serveur (le bout bout). Ainsi, chaque intermdiaire est susceptible de modifier la requte qu'il reoit, souvent en ajoutant son identiti l'intrieur. La mthode TRACE permet donc vritablement de tracer les intermdiaires entre les 2 bouts du rseau. Du point de vue scurit, TRACE offre la possibilit Javascript de voler un cookie dclar SecureOnly ou encore de voler les identits d'authentification HTTP. Plus d'informations ici

III-B-8 - CONNECT
La mthode CONNECT est assez particulire. Elle ne fonctionne que sur les proxies, et permet de demander celuici de relayer une requte sur certains ports, typiquement 443 (HTTPS). Si un client utilisant le proxy a besoin de se connecter via HTTPS, il va alors demander au proxy via la mthode CONNECT, de tunneller ses requtes vers le serveur de destination. A cause de problmes de scurit vidents (voir par exemple ici), les serveurs proxy limitent souvent le port de destination l'unique port 443. La requte CONNECT ne possde comme corps qu'une seule ligne, qui indique le serveur de destination et le port. exemple de requte de type CONNECT
CONNECT developpez.com:443 HTTP/1.1

- 13 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Une rponse positive possible


HTTP/1.1 200 Connection Established Proxy-agent: Apache/2.2.11 (Unix)

Apache n'accepte la mthode CONNECT que sur un port de proxy, et seulement si son module mod_proxy_connect est activ. Sa directive AllowCONNECT permet de dfinir les ports de destination vers lesquels proxier les requtes, si le port demand n'a pas t ouvert par cette mthode, un retour 403 ou 405 est envoy.

- 14 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

IV - Rponses
A toute requte correspond au moins une rponse. Il peut y avoir plusieurs rponses pour une seule requte, comme ce sera le cas dans les transactions partielles.

IV-A - Typographie
La premire chose qu'un serveur doit faire lors de l'envoi de sa rponse, est de fournir de manire concise, rapide et pratique un moyen d'informer le client du rsultat du traitement de sa demande. Le serveur utilise pour cela une ligne de statut comprenant un code de rponse qui tient sur 3 chiffres. exemple de rponse HTTP
HTTP/1.1 200 OK X-Powered-By: PHP/5.2.6 Set-Cookie: bbsessionhash=5dc22176091fde3ea648f61564e566dd; path=/; HttpOnly Cache-Control: private Pragma: private Content-Type: text/html; charset=ISO-8859-1 Content-Encoding: gzip Content-Length: 58840 Date: Fri, 24 Apr 2009 15:05:08 GMT Server: Apache

La rponse commence toujours par une ligne de statut qui rappelle la version de HTTP utilise, puis un code de rponse, suivi de sa description en toutes lettres. Suivent ensuite des en-ttes, et, comme dans le cas de la requte, il peut y avoir un contenu, mais pas tout le temps (cela dpendra de la requte). Une requte HEAD requiert que la rponse n'ait pas de corps, idem pour une requte de type OPTIONS.

IV-B - Codes de retour

- 15 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

2xx 3xx 4xx 5xx

1xx

Succs Redirection Erreur client Erreur Serveur

Information

IV-B-1 - Codes 1xx - Informations


Les codes d'information ont t introduits par HTTP 1.1. Ils ne sont pas toujours bien compris et peuvent prter confusion, par contre ils ne sont que deux.

IV-B-1-a - 100 - Continue


Sans doute le plus mal compris des codes. Ce code est renvoy par un serveur face des requtes particulires (incompltes) d'un client. Imaginons un client qui doive envoyer 300Mo de donnes via une mthode PUT ou POST. S'il envoie sa requte directement, et que le serveur n'est pas dans la capacit de rpondre (la mthode utilise a t interdite par exemple), alors le client va envoyer sur le rseau 300Mo pour rien du tout! Il se retrouvera au bout du compte avec un code de rponse d'erreur, et il aura gaspill du temps, de la bande passante, et sera pass pour un idiot. Au lieu de cela, le client aurait pu demander au serveur "es-tu dans la capacit de rpondre ma requte d'envoi de 300Mo sur cette URL ?". Une rponse du serveur avec un code "100 Continue", indique que "oui, tu peux y aller". exemple de requte demandant si l'envoi d'un fichier (mp3 ici) est possible
PUT /music/mp3/mymusic.mp3 HTTP/1.1 Host: developpez.com Content-Type: audio/mpeg Content-Length: 300000000 Expect: 100-Continue

Le client envoie une requte sans corps, mais avec un en-tte spcial Expect (que nous reverrons plus tard), qui dit qu'il s'attend ce qu'il puisse envoyer le contenu dcrit. exemple de rponse la requte prcdente
HTTP/1.1 100 Continue Date: Fri, 24 Apr 2009 17:05:08 GMT Server: Apache Connection: close

Un serveur ne doit pas retourner un code 100 une requte qui ne possde pas l'en-tte Expect: 100-Continue. Malheureusement, certains rares serveurs le font quand mme. Si un proxy reoit une requte Expect: 100-Continue, il ne doit la faire suivre que si le serveur suivant comprend HTTP 1.1. Dans le cas contraire il doit renvoyer au client d'origine une rponse 417.

IV-B-1-b - 101 - Switching Protocols


Il existe plusieurs versions du protocole HTTP. Aussi, un client peut vouloir changer de protocole (vers des protocoles scuriss, comme TLS) dans sa communication. Pour cel, il peut indiquer au serveur, via l'en-tte Upgrade, la liste des protocoles vers lesquels il souhaite basculer. Si le serveur est d'accord, il rpondre alors par une rponse 101. exemple de requte demandant un changement de protocole
HEAD /ressource HTTP/1.1 - 16 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

exemple de requte demandant un changement de protocole


Host: developpez.com Upgrade: TLS/1.0, SHTTP/1.3, IRC/6.9, RTA/x11 Connection: upgrade

rponse possible
HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0 Connection: upgrade

Apache ne connait pas 101, ce n'est pas encore implment pour prcises

des raisons bien

IV-B-2 - Codes 2xx - Succs


Les codes de succs paraissent simples, mais il y a des subtilits et un rel "langage" respecter; A un type de requte peuvent correspondre plusieurs types de rponses "succs". Les codes 2xx signifient que le serveur "a russi faire ce qu'on lui a demand".

IV-B-2-a - 200 - OK
200 est un code trs classique, car c'est le code de rponse positif une requte GET/HEAD, TRACE ou POST. La rponse contient un corps (un contenu), qui est envoy donc la suite de l'en-tte.

IV-B-2-b - 201 - Created


Ce code est une rponse (positive) une requte de type PUT, ordonnant la cration d'une ressource sur le serveur. Notez que POST peut aussi tre utilise, si un CGI est responsable de cre la ressource, il devra alors rpondre avec ce code. Un en-tte de rponse Location doit tre attach, prcisant l'URL absolue vers la ressource cre (La ressource doit donc exister et tre disponible). Un corps peut tre attach, il doit reprsenter une srie de liens vers la ressource en question.

IV-B-2-c - 202 - Accepted


202 diffre de 201 dans le fait que la demande de cration d'une ressource peut prendre du temps. En gnral, PUT dpose la ressource sur le serveur. POST demande un CGI de traiter la tche. Ce CGI peut lui-mme demander cette cration un programme externe. Il devra alors retourner 202 - Accepted, pour dire que "oui, nous avons pris en compte la requte de cration, nous sommes en train de la traiter". Mieux : la ressource peut trs bien exister, mais ne pas avoir de reprsentation (tre cache), donc une rponse 201 n'est approprie. 202 doit aussi obligatoirement proposer un contenu dcrivant l'tat de traitement de la requte. Un en-tte Location peut ventuellement tre attach, fournissant l'URL d'une page pouvant nous renseigner sur le traitement de la requte. Une requte de type POST, envoi de donnes
POST /livre/create.php HTTP/1.1 Host: developpez.com Content-Type: application/x-www-form-urlencoded Content-length:27 id=32&titre=http%20protocol - 17 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Une rponse positive


HTTP/1.1 202 Accepted Date: Wed, 29 Apr 2009 19:05:03 GMT Server: Apache/2.2.11 (Unix) PHP/5.2.9 Content-Length: 20 Content-Type: text/html; charset=ISO-8859-1 Content-Language: fr <h1>Livre post</h1>

IV-B-2-d - 203 - Non-Authoritative Information


Bouhh, Ce code est carrment inusit ( ma connaissance), et signifie que la rponse renvoye ne provient pas du serveur d'origine. Plutt confu, d'autant plus que le texte officiel dit "Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK)" (que l'utilisation de ce code est facultative et reserve au cas o le code aurait t 200).

IV-B-2-e - 204 - No Content


La rponse neutre. "Ok, j'ai compris : ne bouge pas". En gros, ceci permet au client de discuter avec le serveur, sans que l'affichage n'ait besoin de changer. No Content signifie bien "pas de contenu". Par exemple, l'envoi d'un formulaire qui a dja t envoy, une rponse positive mais vide une requte DELETE, ou encore l'accs un document vide. En rponse une requte POST de type envoi de formulaire, IE8 et FF3 ont fait juste : ils ont rafraichi l'interface graphique, mais sans vider les formulaires, comme si il ne s'tait rien pass (mais pas une erreur en tout cas). Concernant AJAX, c'est au dveloppeur de savoir que "si je reois 204, c'est que c'est OK, point final je n'ai rien faire", afin de bien respecter la norme.

IV-B-2-f - 205 - Reset Content


Requte accepte, la page en cours doit tre "remise zro". Ici ambigut, mme si on sent bien ce que cel signifie. La rponse l'envoi d'un formulaire POST de IE8 se comporte comme en rponse une 200 : page blanche puisque 205 n'est pas supos avoir de corps. S'il y en a un, il sera affich. FF3, lui, semble avoir le mme comportement que face 204, il ne met donc pas zro l'affichage (entendez par l qu'il ne vide pas les formulaires). Le comportement de FF3 n'est pas correct. 205 a t cre dans le but de saisir rapidement plusieurs informations la suite, avec remise zro de la page chaque retour OK. (IE8 ignore lui carrment 205 et le traite comme 200). Une rponse 205 une requte AJAX doit se traiter par la remise zro de l'affichage (remise zro des formulaires).

IV-B-2-g - 206 - Partial Content


206 lie directement une spcificit trs mconnue de HTTP et pourtant tellement gniale : le contenu partiel. Nous n'allons pas dtailler ce processus ici, il le sera plus tard. Simplement : les requtes partielles permettent de ne demander qu'une partie de la ressource (en octets), et non son ensemble d'un coup. 206 indique que la requte partielle (ou requte par parties) a t traite avec succs, le contenu est retourn. De ce fait, l'en-tte Content-Range est obligatoire dans la rponse. Une requte par parties (de type GET)
GET /tutos/http.zip HTTP/1.1 Host: developpez.com Range: 500-1500

- 18 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Une rponse positive


HTTP/1.1 206 Partial Content Date: Wed, 29 Apr 2009 20:14:23 GMT Server: Apache/2.2.11 (Unix) PHP/5.2.9 Accept-Ranges: bytes Content-Range: 500-1500/3587 Content-Type: application/zip Content-Length: 1000 {contenu binaire ici}

IV-B-3 - Codes 3xx - Redirection


Ahhh les fameux "300"... Ils sont mconnus et mal utiliss, mais HTTP y est pour quelque chose car il y a eu de gros changements entre HTTP 1.0 et 1.1. Les codes 3xx dfinissent des contextes de redirection, ils sont donc souvent (voire obligatoirement pour certains) accompagns d'un en-tte Location indiquant l'URL que le client va devoir suivre. HTTP 1.0 ne dfinissait que deux codes de redirections, 301 et 302, c'est maigre. HTTP 1.1 vient renforcer tout cel en en proposant 8 et ils ne sont pas difficiles utiliser, il suffit de lire leur descriptif et de bien l'assimiler en fonction de ce qu'on cherche faire du client.

IV-B-3-a - 300 - Multiple Choices


Ce code de rponse est utilis dans la ngociation de contenu (voir rubrique ddie) pour signaler au client que sa requte comporte plusieurs rponses, et qu'il va devoir effectuer un choix. Ce choix peut tre automatique, mais trs souvent il est manuel : le corps de la rponse doit contenir des liens vers les URLs correspondantes aux diffrentes possibilits. Le navigateur peut ventuellement suivre un ventuel lien propos par le serveur via l'en-tte Location (Firefox et IE8 suivront). Par exemple, le client indique une prfrence de langue quivalente avec un facteur identique pour 2 langues dont le serveur possde des reprsentations. Il est donc impossible pour le serveur de determiner correctement la bonne ressource servir, dans ce cas, il peut soit faire un choix par dfaut, soit proposer une rponse 300 et demander au client de choisir lui-mme. Exemple de requte GET ngociation nulle
GET /tutos/http.zip HTTP/1.1 Host: developpez.com Accept-Language: en,fr;q=0.8

Une rponse indiquant un choix multiple


HTTP/1.1 300 Multiple Choices Date: Wed, 10 Jun 2009 22:27:23 GMT Server: Apache/2.2.11 Content-Length: 243 <html><head> <title>300 Multiple choices</title> </head><body> <h1>Multiple Choices</h1> Available variants: <ul> <li><a href="http.en.zip">http.en.zip</a> , type application/zip, language en</li> <li><a href="http.fr.zip">http.fr.zip</a> , type application/zip, language fr</li> </ul> </body></html>

- 19 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

IV-B-3-b - 301 - Permanently Redirect


"Permanently" est clair : la ressource demande par le client a chang de place dfinitivement. Le client devrait alors suivre l'en-tte Location avec la mme mthode qu'il a utilis. Le problme est que la plupart des navigateurs Web d'aujourd'hui suivent la redirection via une mthode GET, mme si la requte dorigine est POST, en hritage HTTP 1.0. Evitez donc d'utiliser ce code de retour sur une mthode autre que GET (ou HEAD). Dans tous les cas, ce code indique au client qu'il doit mettre jour ses liens pour rfrencer la nouvelle URL. Ceci signifie qu'en thorie, un navigateur Web devrait modifier le lien d'un "favoris", si l'on accde une page depuis un "favoris" (via GET)et qu'elle aboutit sur 301. Les moteurs de recherches, eux, vont mettre jour leur index pour rfrencer la nouvelle URL. Aussi, le corps de la rponse devrait indiquer un lien HTML vers la ressource en question. Exemple de requte GET classique
GET /tutos/http HTTP/1.1 Host: developpez.com

Une rponse indiquant que la ressource n'est plus cet endroit et n'y sera plus
HTTP/1.1 301 Moved Permanently Date: Wed, 3 Jun 2009 22:27:23 GMT Server: Apache/2.2.11 Location: /tutos/http/main.zip Content-Length: 42 {contenu HTML rptant l'URL de Location}

Ce code doit tre utilis pour forcer un moteur de recherche mettre jour un lien dans sa base.

IV-B-3-c - 302 - Found


"Found" signifie que la ressource demande a t localise ailleurs, pensez la notion de "lien" dans les systmes de fichiers Unix. Ainsi, ce code n'est pas correct pour rediriger le traitement d'un POST vers une page d'information car le client est sens garder la mthode qu'il a utilise pour requter la nouvelle URL. Malheureusement l encore, la plupart des navigateurs Web vont utiliser GET alors que ce n'est pas correct et notez que certains clients Web mobiles (tlphones portables) suivent eux la recommendation ... bonjour les dgats si 302 est mal utilis ! Le corps de la rponse devrait indiquer un lien HTML vers la ressource en question, l encore, peu d'applications (types PHP suivent la recommendation. Ce code est celui gnr par dfaut par PHP lorsqu'on indique une redirection via l'ajout un en-tte "Location". Il peut ainsi ne pas tre appropri et devra tre chang le cas chant par le dveloppeur. Voyez la section "Les outils" pour plus d'infos.

IV-B-3-d - 303 - See Other


Voila le code utiliser pour rediriger une requte de type POST vers une ressource qui doit alors tre intrroge via GET. Les navigateurs webs modernes suivent cette recommendation. 303 ne signifie pas que la ressource demande se situe un autre endroit (contrairement 301 ou 302), mais que le rsultat du traitement de la requte originelle (trs souvent POST) se situ tel endroit (indiqu comme toujours par l'en-tte Location). Exemple d'une requte POST, mise jour de donnes
POST /reservations/items/38 HTTP/1.1 Host: developpez.com Content-Type: application/x-www-form-urlencoded Content-Length:20

- 20 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Exemple d'une requte POST, mise jour de donnes


name=exemple&count=4

Une rponse indiquant le statut du traitement de la requte


HTTP/1.1 303 See Other Date: Wed, 3 Jun 2009 22:27:23 GMT Server: Apache/2.2.11 Location: /reservations/items/status/38

IV-B-3-e - 304 - Not Modified


Cette rponse est approprie dans le cadre d'une requte de validation incluant un en-tte de condition comme IfModified-Since ou encore If-None-Match. Elle signifie que la rponse n'a pas chang et que le cache peut mettre jour des paramtres concernant la ressource, comme Last-Modified ou Expires. Certains en-ttes de rponse sont obligatoires (la RFC les indique). Vous trouverez plus d'informations sur le fonctionnement du cache HTTP dans la rubrique approprie. Exemple d'une requte de validation de cache
GET /articles/http/tutoriels/cache.html HTTP/1.1 Host: www.developpez.com If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT If-None-Match: "84d1-3e3073913b100"

Une rponse indiquant un non-changement de la requte


HTTP/1.1 304 Not Modified Date: Wed, 03 Jun 2009 20:56:09 GMT Server: Apache/2 Etag: "84d1-3e3073913b100" Expires: Thu, 04 Jun 2009 02:56:09 GMT Cache-Control: max-age=21600

IV-B-3-f - 305 - Use Proxy


Trs simple : la ressource demande doit tre accder via un proxy obligatoirement. L'adresse du proxy en question doit tre livre dans l'en-tte de rponse Location.

IV-B-3-g - 306 inusit


Ce code a t utilise dans la rdactions des spcifications, puis abandonn. Il n'est donc plus utilis.

IV-B-3-h - 307 - Temporary Redirect


Ce code est utiliser pour rediriger une requte POST vers une page, en conservant la mthode POST originale. Les navigateurs webs modernes suivent cette recommandation et avertiront le client utilisateur via un message que les donnes doivent tre retransmises une URL diffrente. Si une autre mthode est utilise, la redirection prend lieu normalement, mais les clients (comme les moteurs de recherches) ne doivent pas mettre jour leurs liens, la redirection n'est que (thoriquement) permanente. Un en-tte Location doit tre prsent. La diffrence avec 302 est subtile, "Found" ne veut pas dire "Temporary Redirect" dans la smantique profonde des mots, 307 est pour HTTP 1.1 l'ancien 302 de HTTP 1.0 (trs mal utilis des clients). Exemple de requte GET classique
GET /tutos/http.zip HTTP/1.1 Host: developpez.com

- 21 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Une rponse indiquant que la ressource n'est plus cet endroit et n'y sera plus
HTTP/1.1 307 Temporary Redirect Date: Wed, 3 Jun 2009 22:27:23 GMT Server: Apache/2.2.11 Location: /tutos/http/main.zip Content-Length: 42 {contenu HTML rptant l'URL de Location}

IV-B-4 - Codes 4xx - Erreurs client IV-B-5 - Codes 5xx - Erreurs serveur

- 22 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

V - Les en-ttes
Une transaction HTTP, c'est donc une requte suivie d'une rponse. Dans les 2 cas, la "demie-transaction" se dcompose en 2 parties : des en-ttes, la partie obligatoire, et un corps, qui est facultatif. La partie en-ttes se dcompose elle aussi en plusieurs parties.On distingue les en-ttes gnraux (ou globaux), les en-ttes dits "d'entit" dont le rle est de rensigner sur le corps de la demie-transaction, et enfin des en-ttes propres la rponse ou propres la requte.

V-A - Gnraux
Les en-ttes gnraux renseignent sur la demie-transaction HTTP en elle-mme.

V-B - D'entit
Dans le cas o la demie-transaction (requte ou rponse) comporte un corps (du contenu), il convient de dfinir ce corps. Comme il peut tre de tout type, de toute taille, de tout encodage etc..., il convient d'informer la partie rcptrice (le serveur dans le cas d'une requte et le client dans le cas d'une rponse) des caracteristiques du message utile transport (le corps donc).

V-C - De requte
Les requtes sont les demi-transactions HTTP montantes, allant toujours du client vers le serveur. A ce titre, une requte peut tre caractrise par des en-ttes qui n'ont de signification que pour elle.

V-D - De rponse
Les rponses sont les demi-transactions HTTP descendantes, allant toujours du serveur vers le client. A ce titre, une rponse peut tre caractrise par des en-ttes qui n'ont de signification que pour elle.

- 23 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

VI - Transactions partielles
Une transaction HTTP est toujours dcompose en 2 parties : une requte et une rponse. Dans tous les cas, une ressource entre en jeu. Nous avons vu en introduction qu'une ressource tait "un objet" changeable via le web, par exemple un document HTML, un fichier audio ou vido, ou encore un document texte. Les transactions partielles permettent aux 2 parties (client et serveur) de ne s'changer qu'un partie de la ressource, exprime en octets. Le cas d'exemple concrt pour comprendre est le lecteur PDF de Adobe : lorsqu'on possde ce lecteur et que l'on demande via mthode GET la lecture d'un document PDF sur HTTP, le programme de lecture PDF fondu dans le navigateur va prendre la main et demander au serveur de lui servir le document page par page, alors que celui-ci ne reprsente qu'une seule et mme ressource. L'avantage est devinable : le client va pouvoir commencer prendre connaissance du document alors que celui-ci n'est pas encore totallement rapatri. Ce processus de dcoupe d'une ressource en parties a t introduit par HTTP 1.1 et est trs pratique dans certains cas. Toute ressource peut tre sgmente et rapatrie par parties. Si elle pse un certain poids, ou si la qualit de la connexion est dgrade, les requtes partielles prennent tout leur sens. Le principe est simple : le client demande quelle partie (en octet) de la requte il souhaite rcuprer, ceci en envoyant un en-tte Range dans sa requte. La partie demande peut tre borne ("De l'octet 100 500") ou infinie (" partir du 100me octet"). Aussi, le client peut demander plusieurs parties en une seule requte ("de l'octet 10 au 100 et du 200 au 500") : la rponse sera alors une rponse sgmente contenant les parties demandes. Dans tous les cas, si la requte ne peut tre satisfaite (on demande les octets 2456 100, au lieu des 100 2456), alors un code de rponse 416 sera retourn. Exemple de requte partielle
GET /articles/http.zip HTTP/1.1 Host: developpez.com Range: bytes=100-1000

Rponse positive
HTTP/1.1 206 Partial Content Date: Wed, 10 Jun 2009 18:50:59 GMT Server: Apache/2.2.11 Accept-ranges: bytes Content-range: bytes 100-1000/3258 Content-type: application/zip Content-length: 900 { contenu binaire de 900 octets de longueur }

La rponse inclut un en-tte Accept-Range qui signifie que le serveur autorise comme unit de mesure l'octet (c'est le plus classique et il est support par tous les serveurs). On note via Content-Range que le serveur indique bien qu'il rpond la partie demande, et donne aussi le poids total de la ressource (la rponse contient les octets 100 1000 sur un total de 3258). Enfin, Content-Length confirme bien que le corps de la rponse pse 900 octets. Exemple de requte incorrecte : la borne maximale est infrieure la borne minimale
GET /articles/http.zip HTTP/1.1 Host: developpez.com Range: bytes=1000-100

Rponse positive
HTTP/1.1 416 Requested Range Not Satisfiable - 24 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Rponse positive

Date: Wed, 10 Jun 2009 18:57:17 GMT Server: Apache/2.2.11 Content-type: application/zip

Enfin voici un exemple de demande de plusieurs parties en une seule requte: Exemple de demande de plusieurs parties
GET /articles/http.html HTTP/1.1 Host: developpez.com Range: bytes=100-1000, 1500-1900

Rponse positive contenant plusieurs parties d'une mme ressource dcoupe


HTTP/1.1 206 Partial Content Date: Wed, 10 Jun 2009 19:15:04 GMT Server: Apache/2.2.11 Accept-ranges: bytes Content-length: 1673 Content-type: multipart/byteranges; boundary=46c03675fc9384ac --46c03675fc9384ac Content-type: text/html Content-range: bytes 100-1000/15869 {#### premier contenu de 900 octets #####} --46c03675fc9384ac Content-type: text/html Content-range: bytes 1500-1900/15869 {#### deuxime contenu de 400 octets #####} --46c03675fc9384ac--

La rponse est sgmente grce un joker de contrle appel "boundary" qui dlimite les parties dans le corps de la rponse. Chaque partie rpte certains en-tte notamment le type MIME. Cette technique est la mme qui est utilise par exemple dans les protocoles mails (SMTP) pour grer les "pices jointes". Notez que le Content-Length contient bien le poids total du corps de la rponse, soit le poids des parties + les 3 rptitions de la chaine joker et les multiples en-ttes crits (Content-Length reprsente toujours le poids total du corps en octets).

- 25 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

VII - Proxies
Les proxies sont trs utiliss de nos jours, sur le Web notamment. Nous allons tenter d'expliquer leur fonctionnement et leur utilit.

VII-A - Dfinitions
Un proxy est un serveur qui va agir la place d'un autre. C'est une machine intercale sur le rseau, qui souvent "prend la place" logique d'une autre. On distingue 2 cas de proxies HTTP : forward ou reverse, et il est trs important de comprendre la diffrence entre un forward et un reverse proxy. Dans un forward proxy, les clients demandent un serveur de relayer la requte vers le serveur de destination. Cela se fait gnralement en rglant le navigateur et en lui spcifiant un proxy utiliser (pas toujours, on peut aussi rgler le rseau pour utiliser un proxy de manire totalement transparente). En entreprise, c'est assez courant : le firewall bloque le port 80, les clients doivent donc obligatoirement passer par le proxy pour aller surfer sur le Web. Le proxy va alors souvent mettre en cache des ressources qu'il pourra resservir diffrents clients

Une configuration en forward proxy Dans un reverse proxy, les utilisateurs accdent un contenu sur un serveur (par exemple http://serveur/page/ ressource) mais ce contenu n'est en ralit pas stock sur ce serveur. Celui-ci va alors agir comme un proxy vers le serveur de destination. Ces serveurs proxy l peuvent aussi jouer un rle dans l'quilibrage de charge (load balancing), ils peuvent par exemple contacter plusieurs serveurs de destination en fonction de leur charge respective, mais ceci dpasse le cadre de cet article.

- 26 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Une configuration en reverse proxy Il est bien sr possible de mixer le forward et le reverse proxy, et il est aussi possible que plusieurs proxies relayent la requte du client entre eux en crant alors un chemin de proxies. Le but principal des proxies HTTP est souvent le mme : si une machine proxy proche du client possde la ressource demande et que celle-ci est valide, la chaine va alors tre brise et le serveur d'origine (ainsi que les ventuels proxies intermdiaires ventuels) ne sera alors pas contact. Il existe des protocoles, comme "ICP" (Inter Cache Protocol), capables de faire communiquer les caches entre eux, dans des relations parents/enfants. Cela dpasse le cadre de cet article, notez simplement quelques protocoles s'ils vous intressent : ICP, CARP, HTC et WCCP).

VII-B - Rles
Les rles d'un proxy HTTP sont trs divers : 1 Cache: C'est clairement le rle principal et la partie sur laquelle nous allons nous tendre dans le chapitre suivant, un proxy va pouvoir mettre en cache une ressource qu'un client A lui demande, et ventuellement la resservir un client B la demandant plus tard. Il y a donc conomie de bande passante et de latence rseau, car le serveur original dissimul derrire le (ou les) proxy n'est pas rintrrog et souvent le serveur proxy se situe physiquement proche des clients (donc un routage et une latence optimale). Authentification: Un proxy peut demander ses utilisateurs de s'authentifier avec lui avant de pouvoir l'utiliser. C'est un processus simple de contrle de l'accs au web. Filtrage de requte: Trs la mode dans les entreprises, un proxy va pouvoir interdir telle ou telle requte tel ou tel client. L'exemple typique est le cas des sites caractres pornographiques, ou encore les sites de partage de vidos. Une liste de sites est alors charge dans le serveur proxy, qui l'analyse chaque requte de client. Filtrage de rponse: Plus rare mais tout aussi possible, le proxy va analyser la source (HTML souvent) de la rponse, et remplacer des parties de codes avant d'envoyer la rponse modifie au client. Typiquement il pourra s'agir de plublicits ou encore de javascripts malicieux. Notez que les reverses proxies utilisent une telle technique pour rcrire les liens des pages afin qu'ils ne comportent pas d'indication sur le serveur de destination. Apache permet ceci via mod_proxy_html. Balance de charge: Un proxy peut aiguiller certains clients, sur cetains serveurs, en fonction de la ressource demande. C'est assez rare, d'autres solutions plus adaptes et jouant avec les couches basses d'OSI existent. (Voyez mod_proxy_balancer de Apache)

2 3

- 27 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Prchargement: Charger des donnes avant mme qu'un client ne les demande, en supposant qu'il va les demander dans le futur. Le cas classique des images d'une page HTML est trs explicite : le proxy tlcharge en avance les images sur le serveur original, la seconde mme ou le client lui a demand la page HTML les comportant. Transcodage: Le proxy peut traduire ou transcoder les caractres d'une page, en fonction des prfrences linguistiques du client et de la rponse du serveur. Il existe sur l'Internet des tonnes de proxies HTTP. La plupart sont des reverse, et en entreprise, souvent, des forwards proxies sont prsents. Les tches principales d'un proxy HTTP sont le cache et le filtrage, notamment en entreprise. Souvent, un proxy signale qu'il a t utilis en rajoutant sa signature au travers d'un entte spcifique : "Via"; mais a n'est pas obligatoire : un proxy peut alors agir de manire totalement transparente, et il demeure impossible de savoir qu'il est l premire vue. Certes, une analyse bas niveau du rseau au moyen de mtrace, traceroute ou autres outils Linux permettra de dcouvrir les proxies sur le chemin.

VII-C - La mise en place sur les clients


Pour mettre en place un forward proxy sur un client (navigateur), il existe 3 mthodes : 1 2 3 Indiquer explicitement au client quel serveur utiliser comme proxy Indiquer explicitement au client un script javascript qui va determiner le serveur proxy utiliser Utiliser du filtrage rseau bas niveau pour rerouter la requte de manire transparente vers un proxy

Dans le cas d'une mise en place manuelle, il faut configurer chaque client. Pour Firefox, il suffit d'aller dans les options avances du rseau, et indiquer le serveur et le port du proxy. Pour les programmes comme wget ou lynx, ils scrutent une variable d'environnement "http_proxy". L'autre mthode consiste indiquer l'adresse URL vers un script PAC (Proxy Auto Configuration) crit en javascript, qui devra alors retourner l'adresse d'un serveur proxy que le navigateur utilisera alors pour effectuer sa requte. Cette technique est pratique dans le cas d'une entreprise, car tous les navigateurs auront dans leur configuration le mme fichier PAC qu'il suffira alors de changer pour repercuter les modifications partout. Le script PAC va pouvoir aussi faire tourner les adresses des serveurs proxy qu'il retourne, en fonction du hasard ou de la requte effectue (quilibrage de charge) La valeur de retour d'un telle fonction est de la forme :
PROXY host:port SOCKS host:port DIRECT

Il est important de noter que ce script doit tre situ sur un serveur HTTP accessible du client, et doit tre retourn avec un en-tte "Content-Type: application/x-ns-proxy-autoconfig" sinon il ne sera pas reconnu comme script de configuration automatique par les navigateurs Webs. Le PAC a t invent par Netscape dans sa version 2 et est encore largement utilis en entreprise de nos jours. Enfin la troisime mthode, elle, est totalement transparente. On appelle cel un "proxy d'interception" (et non pas un proxy transparent). Ceci consiste modifier les rgles de routage du routeur physique qui se charge de la requte, afin de dtecter s'il s'agit d'une requte HTTP (port 80). Si c'est le cas, la requte est alors route vers un serveur proxy. Cisco propose des protocoles pour cela, certains switchs matriels aussi (le firmware DD-WRT propose cela), mais sinon, toute machine UNIX peut faire l'affaire. Nous allons prendre comme exemple une machine Linux avec un noyau suprieur 2.4 (autorisant la fonction iptables) routage bas niveau pour proxy d'interception
> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j REDIRECT --to-ports 8080

- 28 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Ce code suppose que la machine de routage est la mme que la machine qui heberge le proxy. Sinon, il faudra faire du NAT de source et de destination. Tout le monde peut tester ceci, il suffit d'une machine Linux avec un noyau 2.4 ou plus et de 2 cartes rseaux. Bien sr il faudrait complter un tel script de manire ce que si le proxy ne fonctionne plus, le traffic soit libr.

VII-D - Exemple pratique


Squid est un excellent produit, il s'agit d'un programme ddi la tche de proxy HTTP. Cependant nous allons baser un exemple pratique avec Apache et mod_proxy. Il s'agit tout d'abord de compiler Apache avec le support du proxy. Nous ne nous interessons qu' HTTP, le proxy FTP est autre chose, non abord ici : Ligne basique de compilation d'Apache
./configure --enable-modules=proxy proxy_http make make install

Si vous voulez qu'Apache proxie tout le temps (et non ponctuellement), compilez les modules en statique comme dans l'exemple si dessus : vous gagnerez en performance face un chargement dynamique (DSO) Attention, mod_proxy n'effectue aucune opration de cache, cette tche est dlgue mod_cache et ses amis. Attention, mod_proxy ne sait proxier les demandes de tunnel HTTPS (mthode CONNECT), il faut pour cela compiler mod_proxy_connect en plus. Passons la configuration du serveur. En gnral, un forward proxy n'coute pas sur le port 80 rserv au service HTTP. Il est usuel d'utiliser 8080, c'est ce que nous allons faire : Configuration d'Apache pour agir en forward proxy
Listen 8080 NameVirtualHost *:8080 <VirtualHost *:8080> ServerName proxy.jp-developpez ProxyRequests On ProxyVia On <Proxy *> Order deny,allow Allow from 192.168 Allow from 127.0.0.1 Deny from all </Proxy> ProxyBlock verybadsite.com ProxyRemote * http://the-second-proxy.com:8080 LogFormat "From:%h(%a) at %t for \"%r\" \n %V responded: %>s (at %s) -%B bytes- %f" proxycommon CustomLog logs/proxy.log proxycommon ErrorDocument 403 "<h1>Forbidden</h1> This port should be used as a proxy" <Directory /> Order allow,deny Deny from all </Directory> </VirtualHost>

- 29 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Toutes ces directives sont clairement documentes dans la documentation officielle de Apache, j'en passe tout de mme quelques une en revue : 1 2 3 4 5 6 7 ProxyRequest : permet Apache d'agir comme forward proxy ProxyVia : Apache va indiquer dans les rponses ses clients qu'il a t utilis comme proxy dans la requte <Proxy *> : Trs important, permet de limiter l'usage du proxy certains clients identifis par leurs adresses IP. Faites trs attention de ne pas ouvrir un proxy sur le Web, vous serviriez alors de relai tout et n'importe quoi, c'est trs dangereux. ProxyBlock empche l'accs certains sites par domaine ou adresses IP. Un proxy peut donc filtrer le traffic qui passe par lui et ventuellement le bloquer totalement. ProxyRemote indique un proxy vers qui relayer formant ainsi le dbut d'une chaine de proxies. Ici, toutes les requtes proxies par Apache le seront non pas vers le serveur de destination, mais vers un autre serveur proxy. LogFormat et CustomLog permettent d'enregistrer toutes les requtes des clients ErrorDocument et Directory permettent d'empcher quelqu'un d'accder ce port 8080 de manire directe, via l'URL

Il suffit maintenant d'indiquer ce serveur comme proxy dans les navigateurs des clients, et le tour est jou. mod_proxy ne supporte pas encore les proxies transparents. Pour cel, vous devez indiquer RewriteEngine on RewriteCond %{THE_REQUEST} ^[A-Z]{3,5}\ (/[^?\ ]*) RewriteRule ^/ http://%{HTTP_HOST}%1 [NE,P] dans votre VirtualHost. Ceci permet de rcrire la requte en une requte de proxy. Un proxy repre une requte proxier grce la ligne de requte. Une requte vers un proxy comporte toute l'URL dans la ligne de requte, et non juste la ressource demande. Cette transformation est mise en oeuvre par les clients HTTP usuels, ainsi en cas de proxy transparent, cette transformation n'est pas effectue.

- 30 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

VIII - Le cache
Depuis la conception de HTTP 1.0, l'conomie de ressources par le cache a t pens. Globalement, le cache HTTP permet un client de ne pas retlcharger une ressource si celle-ci est encore, ou a une grande probabilit d'tre encore valide dans un cache (gnralement situ proche du client afin de raccourcir au maximum le temps de rponse) Le cache HTTP a t cre avec 3 objectifs accomplir : 1 2 3 Faire en sorte que les pages webs chargent plus vite (rduire la latence) Rduire la bande passante globale consomme Rduire la charge sur le(s) serveur(s) proposant la ressource

HTTP 1.0 propose une solution trs basique de cache de ressources, nous la dtaillerons. HTTP 1.1 fournit un mcanisme beaucoup plus complet et complexe de gestion du cache, nous le dtaillerons aussi et noterons les diffrences avec HTTP 1.0. Mme si cela n'est pas trs franais, nous parlerons de donne "cachable" ou encore de donne "cache" (non pas dans le sens "invisible" mais dans le sens "stocke dans un cache")

VIII-A - Dfinitions
La latence reprsente le temps que met une requte pour arriver sa destination. Cet article n'tant pas orient rseau, sachez simplement qu'il existe des algorithmes d'une complxit incroyable permettant un paquet IP de "choisir la meilleure route" pour arriver d'un point A un point B. Or, il arrive dans certains cas (pensez une finale de coupe du monde fraichement remporte) que le rseau soit surcharg. Vont alors apparaitre des files d'attentes dans les routeurs Internet, et une partie du traffic devra trouver une route plus longue que la normale. Dans le meilleur des cas, le cache permet d'viter totalement la requte, dans un cas moins bon, il permet de router la requte de manire plus approprie (au moyen de proxies). Le problme de la bande passante, lui, est simple comprendre : elle cote (trs) cher et au moins un client en consomme, au plus son fournisseur est heureux. Ainsi, si un client peut charger une ressource HTTP depuis un cache sur son rseau local, plutt que d'en sortir par sa passerelle pour aller sur le Web, c'est alors de la bande passante Web conomise. Idem concernant la charge des serveurs, on comprend rapidement qu'au moins un serveur est charg (au moins il traite de clients la seconde), au plus il sera ractif. Il existe diffrents types de cache qu'il faut bien diffrencier : 1 2 Les caches privs : se sont les caches intgrs aux clients web de type navigateurs webs, ils peuvent tre mmoires (RAM), ou disques. Les caches publics : se sont des caches partags : des machines proxy (forward proxy) situes entre des clients et un/des serveurs. Ils peuvent tre volontaires, ou alors forcs (invisibles) Quoiqu'il arrive, il faut bien distinguer le cache public du cache priv. Le cache priv est (par dfinition) propre un seul client : c'est son navigateur, et ce cache l est dsactivable ou configurable selon les navigateurs Un cache public (reverse ou forward proxy) est partag entre plusieurs clients, et l il va s'agir de faire trs attention de ne pas afficher la page de l'utilisateur "toto", l'utilisateur "titi". Ainsi, les mcanismes de cache HTTP paraissent souvent confus et compliqus, alors qu'ils ne le sont pas. Ils sont simplement "touffus" : il y a pas mal de paramtres qui peuvent entrer en jeu.

- 31 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Sous Firefox, tapez "about:config" dans la barre d'adresse et validez. Les paramtres network.http.use-cache, et browser.cache.*** servent grer le cache priv. Voyez http://kb.mozillazine.org/About:config_entries pour plus d'infos, et faites attention de ne pas "jouer" avec ses paramtres l'aveugle : vous risquez de bloquer votre navigation ou de devenir un "mauvais client" web. Sous Firefox toujours : taper F5 demande une revalidation de la ressource envers le serveur de destination, alors que taper ctrl+F5 demande de sauter tous les proxies et de contacter directement le serveur de destination et dsactive donc le cache lors du rafraichissement. Lorsqu'un client demande une ressource et que la rponse provient d'un cache, on appelle cela un "cache hit". Si la rponse au contraire est issue du serveur original, il s'agira d'un "cache miss" Le ratio cache hit / cache miss donne la performance globale d'un serveur de cache. Il faudra par contre porter une attention trs particulire la "fraicheur" des donnes. En effet, lorsqu'on demande un cache une ressource, il doit tre capable de savoir si celle qu'il possde en lui est fraiche (il peut alors la servir lui mme au client), ou prime (il doit alors contacter le serveur d'origine pour lui demander une copie fraiche). Pour dterminer la fraicheur d'une ressource, le cache possde 2 solutions : soit la ressource a dclar elle-mme (c'est le comportement conseill) sa priode de fraicheur aux moyens d'en-ttes HTTP que nous allons dtailler, soit alors le cache doit faire appel des heuristiques (des lois d'hypothses mathmatiques) afin de deviner (de supposer) si la ressource est fraiche ou prime.

VIII-B - Le fonctionnement
Un cache est donc soit un proxy (cache public : une machine physique situe entre le client et le serveur de destination), soit un navigateur web (cache priv). Comment fonctionne le cache ? Dans un premier temps, il convient de dterminer si la ressource demande est "cachable", car elles ne le sont pas toutes. Pour cela, il faut analyser : 1 2 3 4 Le code de rponse Le type de requte Les en-ttes Expires, Cache-Control et Pragma La prsence ou non, d'un mcanisme d'authentification

La gestion du cache sur HTTP est un jeu complexe entre tous ces paramtres, dont certains ont une priorit suprieure d'autres. Le but est toujours le mme : faire pour le mieux, c'est dire fournir un maximum de donnes depuis le cache aux clients et un maximum de donnes valides, c'est dire n'ayant pas chang entre temps. Tout un programme !

Le cache en fonction des mthodes de requte


GET: Toujours cachable par dfaut, sauf si un en-tte de cache prcise le contraire. HEAD: Peut tre utilis pour mettre jour la donne prcdemment cache. POST: Non cachable par dfaut, sauf si un en-tte de cache prcise le contraire. PUT: Cache interdit DELETE: Cache interdit OPTIONS: Cache interdit TRACE: Cache interdit

Voici dja un bon point, il faut savoir que certains serveurs ou clients peuvent passer outre ces recommendations fournies par la RFC, mme si c'est bien entendu fortement dconseill. Ainsi, les en-ttes de cache que sont Cache-Control et Expires sont maitres, car ils peuvent changer les comportements par dfaut de certaines mthodes de requte HTTP. Petite note concernant HEAD. Nous avons vu que cette mthode de requte ne contient pas de corps, et que sa rponse non plus. HEAD n'est donc pas cachable, cela n'a pas

- 32 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

de sens, mais HEAD peut tre utilise pour lire les en-ttes de rponse et mettre jour un cache trop vieux (on parle de validation du cache).

VIII-B-1 - Au coeur du mcanisme de cache de HTTP 1.0


HTTP 1.0 proposait un mcanisme de cache sommaire, mais qui continue aujourd'hui de fonctionner et de suffir dans de nombreux cas (car pour rappel HTTP 1.1 est compatible 1.0). Une rponse d'un serveur doit toujours comporter un en-tte Date, ceci est obligatoire, mais encore aujourd'hui certains (trs rares) ne l'envoient pas. Ce champ va servir au cache faire des calculs. Commenons par les plus simples : toute rponse comportant un en-tte Expires est cachable. Mme une requte POST normallement non cachable le devient si un en-tte Expires est prsent dans la rponse. Si un client sait quand est-ce qu'expire une ressource, il pourra alors sans problme se servir dans son cache (pour un navigateur web, il se servira sur le disque dur ou dans la mmoire vive) chaque demande de cette ressource, jusqu' ce que la date spcifie par Expires soit atteinte ou dpasse. Idem pour les cache publics (les proxies). Expires vite donc au client HTTP de demander la ressource, mais vite aussi toute requte de validation, c'est dire demander si la ressource est toujours "fraiche" en cache. Concernant les ressources dont on sait qu'elles ne changeront pas (images, css, js, etc...) il FAUT envoyer un en-tte Expires. Trop peu de concepteurs d'applications sur le web oublient cette vidence pourtant tellement simple et salvatrice de bande passante, de rseau, etc... Attention, il est indiqu dans la RFC de ne pas dpasser un dlai de 1 an dans Expires (date actuelle + 1 an maximum). Une rponse cachable
HTTP/1.1 200 OK Date: Sun, 04 May 2009 18:27:12 GMT Content-Type: image/gif Expires: Sun, 12 May 2009 18:27:12 GMT Connection: Keep-Alive

Une rponse invalide car pas d'en-tte 'Date:', elle peut par contre tre accpte par un client de manire transparente
HTTP/1.1 200 OK Content-Type: image/gif Connection: Keep-Alive

C'est simple : si la date indique par Expires est suprieur celle de l'en-tte Date (c'est le cas de notre premier exemple ci-dessus), alors le cache sait que la donne est non-seulement cachable, mais il sait aussi quand est-ce qu'il devra demander au serveur d'origine de revalider la donne (via une requte HEAD par exemple). Il ne le fera pas avant, sauf si on le force (typiquement : rafraichissement volontaire de la page par pression sur F5). Un en-tte Expires exactement gal l'en-tte Date signifie que la ressource est cachable, mais devra tre revalide ds la prochaine requte (c'est aussi le cas avec une valeur de Expires 0) Pour dsactiver le cache en HTTP 1.0, utilisez Pragma: no-cache. Sous Apache, le champ Expires n'est pas gr par dfaut, il faut pour cel activer le mod_expires et le configurer. Notons que les en-ttes Date comme Expires expriment une date calendaire ce qui mne souvent des problmes de synchronisation d'horloge car des serveurs peuvent avoir une horloge drgle ou dcale. La date est toujours spcifie GMT, les dcalages horaires ne reprsentent donc pas un problme. Une solution aux problmes de synchronisation a t trouve et implmente dans HTTP 1.1.

- 33 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Passons l'en-tte de rponse Last-Modified. Du mme format que Date (une date calendaire), il indique au client la date laquelle la ressource est suppose avoir t modifie pour la dernire fois. Pour un fichier statique, le serveur HTTP interroge simplement le systme de fichier. Pour les ressources "dynamiques" (CGI, PHP etc...), c'est au dveloppeur penser fournir cet en-tte, car le serveur ne le fera pas par dfaut, sauf si on le configure pour (mod_header de Apache). Last-Modified va servir la validation de la ressource. Lorsque la date indique par Expires est dpass, ou lorsque l'en-tte Expires est absent de la rponse, la prochaine demande de la ressource concerne, le cache va effectuer une requte conditionnelle au moyen de l'en-tte If-Modified-Since. Si la ressource n'a pas chang depuis cette date, une rponse 304 Not-Modified sera retourne (sans le contenu de la ressource en question, bien entendu) et le cache considrera alors cette ressource comme toujours fraiche. Mieux que cel : le cache va alors mettre jour la Date de cet lement dans son espace de stockage et pourra effectuer des calculs de "vieillesse" et de frquence de demande de cette ressource l, afin de mieux grer son espace de stockage. Le facteur appell LM-age, (LM - Date) va servir au cache dans des statistiques de calcul concernant la ressource. En conclusion, l'absence de Expires dans la rponse ne va pas empcher le cache (attention tout de mme : voir les mthodes HTTP cachables) mais va faire provoquer au cache une demande de validation envers le serveur de destination chaque requte de la ressource. L'absence de Last-Modified dans la rponse inhibe le processus de validation, et le cache ne pourra alors pas savoir si la ressource a chang ou pas, lorsqu'il a besoin de la valider : ceci amne donc la redemande complte de la ressource envers le serveur de destination et une perte lourde dans l'intert du cache HTTP (Apache par exemple, envoie systmatiquement un en-tte Last-Modified sur un contenu "statique"). L'absence la fois de Expires et Last-Modified annule tout mcanisme de cache (recommand par la RFC)

VIII-B-2 - Au coeur du mcanisme de cache de HTTP 1.1


HTTP 1.1 apporte un mcanisme de cache beaucoup plus pouss et dtaill que celui implment dans HTTP 1.0 (qui n'en demeure pas moins efficace tout de mme). Tout va se jouer sur l'en-tte Cache-Control, rellement spcifique HTTP 1.1. Cet en-tte peut la fois faire partie d'une requte comme d'une rponse. Nous analyserons ici sa position dans une rponse HTTP. Cache-Control va permettre de grer trs finement la fois les processus de cache (navigateur et proxies, ou encore caches publics et privs, vont tre diffrencis), mais aussi le processus de validation. Il va aussi donner une rponse au problme des dates au format calendaire. Cache-Control: private indique que les caches privs (navigateurs) peuvent stocker la ressource, mais pas les caches publics (proxies). Pratique lorsqu'il s'agit d'informations propres un utilisateur. Cette directive rend cachable toute rponse qui ne l'est pas par dfaut (rponse POST par exemple). Cache-Control: public autorise le stockage par les caches publics et privs. C'est aussi le seul en-tte qui autorise les caches, notamment les proxies, stocker une rponse une requte demandant authentification. Cache-Control: no-cache est un faux-ami, ceci n'indique pas d'viter tout prix de mettre en cache la rponse! Cette directive oblige les caches privs ou publics systmatiquement revalider la ressource chaque demande, et ne jamais supposer qu'elle sont valides au sein du cache sans revrifier ceci sur le serveur de destination. Un cas particulier concerne la spcification d'un en-tte de rponse derrire no-cache : Cache-Control: no-cache=Setcookie par exemple indique aux caches de ne pas stocker cet en-tte de rponse dans le cache. Trs important pour les cookies de session! Cache-Control: no-store. Voici la directive interdisant la mise en cache de la rponse, quel que soit le cache considr. (Notons que si cet en-tte est un en-tte de requte, il indique alors que la rponse doit comporter la mme directive, et donc ne pas tre cachable).

- 34 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Certains serveurs, comme Apache, proposent des directives permettant volontairement de violer le protocole, et de mettre en cache des rponses malgrs des en-ttes indiquant le contraire. Il est bien entendu hautement recommand de ne pas utiliser de telles directives. Cache-Control: must-revalidate va indiquer un cache que la ressource doit tre revalide si elle arrive expiration. Comme c'est thoriquement le cas par dfaut, cet en-tte est confu et utilis dans le cas ou le cache (proxy typiquement) serait tent de retourner une rponse expire sans la revalider (congestion rseau par exemple). Cette directive autorise aussi le cache de ressources qui n'taient pas cachables l'origine (rponses soumises authentification par exemple). Cache-Control: proxy-revalidate est indentique mais concernant les caches publics. Cache-Control: max-age=xxx max-age corrige le problme des dates en donnant un temps relatifs la date de la rponse, pendant lequel le contenu est toujours valides. Cet en-tte peut donc remplacer Expires en HTTP1.1 et de ce fait, permet la mise en cache d'une ressource mme si celle-ci n'est par dfaut pas cachable. Cache-Control: s-maxage=xxx s-maxage est identique max-age, mais ne s'applique qu'aux caches publics : les proxies. Cache-Control: no-transform Cette directive indique aux proxies de ne pas transformer la ressource. Certains proxies peuvent r-encoder des images, ou compresser la ressource pour plus d'efficacit. Cette directive leur indique de ne pas transformer celle-ci, de quelque manire que ce soit. Cache-Control: max-stale:xxx Un en-tte de requte indiquant qu'un client accepte des rponses non fraiches. Si un proxy s'aperoit que la ressource a expir, il va tenter de la revalider. Si la revalidation choue, le proxy est autoris renvoyer la ressource vieille depuis son cache, et non valide (celle-ci peut alors tre erronne car elle a pu chang). Le client indique via max-stale qu'il accepte des rponses risquant d'tre erronnes, mais la rponse devra le spcifier par un Warning: 110 Response is stale par exemple.

VIII-B-3 - Fraicheur des donnes, validations et requtes partielles


Lorsqu'une ressource a expir, le cache (priv ou public) doit la revalider. Il est aussi possible de demander revalidation explicitement, quel que soit l'ge de la ressource, grce 3 mcanismes : Cache-Control: no-cache, Cache-Control: max-age=0 ou Cache-Control: must-revalidate. La validation se fait par une "requte partielle", qui consiste simplement demander "La ressource XXX a-t-elle chang ?". Il existe alors 2 manires de faire. La requte conditionnelle sur Last-Modified. Toute rponse cachable devrait inclure un en-tte Last-Modified qui prcise la date de modification de la ressource. Le cache peut ainsi forger une requte conditionnelle If-ModifiedSince afin de valider la fraicheur de la ressource expire (ou non : force tre revalide) par rapport cette date l: Validation d'une ressource
HEAD /path/to/resource HTTP/1.1 If-Modified-Since: Fri, 11 Sep 2009 11:28:49 GMT

Une rponse ngative sera de type 200 et refournira la ressource complte que le cache mettra jour. Une rponse positive en revanche, sera de type 304 et incluera une Date et un nouvel en-tte Expires qui pemettront au cache de se mettre jour afin d'ventuellement prolonger la dure de vie da la ressource. Last-Modified est trs important aussi pour calculer la fraicheur de la donne que l'on appelle le "LM factor". En soustrayant la date de Last-Modified la date de Date, un cache peut ainsi estimer la fraicheur de la ressource et organiser son espace de stockage en consquence. Par exemple il pourra supposer qu'une ressource ayant un LM-factor petit vient de changer, et sera plus susceptible de changer encore qu'une autre ressource ayant un plus grand LM factor.

- 35 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Last-Modified prsente cependant quelques problmes : echelle de une seconde (si la ressource change 8 fois par seconde ?), problme de synchronisation des horloges, et problme lors de la copie de ressources sur le serveur, altrant la date de modification du fichier alors que celui-ci n'a pas chang (cp -p sous Linux pour pallier ce problme). Un autre systme de validation existe aussi : l'entity tag (Etag) L'Etag est calcul en fonction de facteurs (dpend des programmes) et se prsente de cette manire : Une rponse incluant un Etag
HTTP/1.1 200 OK Date: Fri, 11 Sep 2009 11:28:49 GMT ETag: "8eca4-205f-17b94c"

La requte conditionnelle utilise alors "If-None-Match" : Requte de validation utilisant l'Etag


HEAD /path/to/resource HTTP/1.1 If-None-Match "8eca4-205f-17b94c"

Si le tag est valide, une 304 sera retourne. HTTP autorise par contre un serveur utiliser plusieurs tags pour une seule ressource. Un cache peut stocker plusieurs versions de la mme ressource, avec des tags diffrents, d'o le "If-None-Match" qu'on peut traduire par "Si aucun Tag ne correspond". On peut donc voir des requtes de validation comme : Requte de validation utilisant plusieurs valeurs d'Etag
HEAD /path/to/resource HTTP/1.1 If-None-Match "foo", "bar", "baz"

Attention car les ETags sont gnrallement calcul par serveur (voyez le mcanisme de calcul de votre cache en lisant sa doc technique), et souvent bas sur l'inode du fichier. Ainsi si un tourniquet est mis en place, un client pourrait contacter un serveur d'abord, puis un autre ensuite mais concernant la mme ressource. Comme les deux serveurs n'ont pas le mme Etag, la validation chouera et la ressource sera alors retlcharge.

VIII-B-4 - Provoquer le cache ou l'viter


Pfiouuu, que d'informations (et encore, c'est non exhaustif hein). Le mieux est que chacun fasse des TPs de son cot ;-) Avec les machines virtuelles en plus de nos jours, c'est trs facile de tester un produit ou mme plusieurs (et de crer des chaines de proxies). Bon, pour y voir plus clair quand mme, dans un premier temps, comment provoquer le cache de ressources ? 1 2 3 4 5 6 7 8 Si vous connaissez le principe des SSI (Server Side Includes) : ceux-ci sont pas dfinition non cachables : vitez les Utilisez GET. POST n'est par dfaut pas cachable et c'est logique quand on sait quoi sert POST Ne renommez pas les fichiers sur votre serveur : ils compteront comme de nouvelles ressources et feront chouer le cache et la validation Utilisez Expires, c'est l'en-tte magique le plus puissant pour le cache Utilisez Last-Modified, vous aiderez normment le cache lors de la validation de la requte. Vous l'aiderez aussi pour ses calculs internes de fraicheur. Last-Modified est presque aussi important que Expires, c'est le duo de choc pour provoquer le cache Si vous utilisez du CGI et du contenu statique, sparez les physiquement sur 2 serveurs diffrents. Les serveurs s'en sortent bien concernant le contenu statique : ils peuvent tout faire eux-mmes, alors que sur le CGI c'est aux dveloppeurs de tout implmenter la main N'utilisez pas la ngociation de contenu, ou alors rglez le trs finement grce l'en-tte Vary N'utilisez pas l'authentification HTTP, elle provoquera par dfaut la dsactivation de tout mcanisme de cache

- 36 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

Si vous n'aimez pas les proxies, proposez tout de mme la mise en cache niveau navigateur, grce CacheControl: private

Ou au contraire, voyons quelques recommandations sur comment viter le cache ? 1 2 Plutt que d'viter le cache tout prix, prfrez spcifier que vous voulez systmatiquement revalider vos ressources tous niveaux. Un cache-control: no-cache est trs efficace pour cela Pour dsactiver vraiment le cache, utilisez alors Cache-control: no-store ou son quivalent HTTP 1.0 Pragma: no-cache

- 37 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

IX - L'authentification

- 38 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

X - Ngociation de contenu

- 39 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

XI - Gestion des connexions TCP avec HTTP


HTTP est un protocole de niveau 7 OSI sur la couche applicative. Il est donc port par tous les protocoles de niveau infrieur. Sans entrer dans les dtails d'OSI, HTTP utilise la couche transport TCP (port 80), avec tous les avantages et les inconvnients de ce protocole. Nous n'allons pas faire un cours sur TCP, mais simplement rappeler (trs globalement) que l'avantage de TCP rside dans son mode "connect". TCP effectue un lourd travail permettant d'assurer que les donnes transportes ont bien t reues (dtection d'erreurs et accuss de rception), elles sont intgres (dtection d'erreurs et r-mission ventuelle) et numrotes ce qui permet de les recomposer l'autre bout de la connexion. La machine rceptrice envoie pour chaque paquet TCP un accus de rception, et les 2 machines en communication ngocient la taille et la segmentation des donnes en paquets. TCP est donc un protocole d'une grande fiabilit et ceci a un cot. Les mcanismes de connexion de TCP imposent une poigne de main en 3 temps entre les 2 machines. Lorsqu'une machine mtrice dsire envoyer des donnes, elle doit d'abord ouvrir une connexion (tape 1). La machine rcptrice indique alors qu'elle est l, et qu'elle accepte la connexion (tape 2). Enfin, la machine mtrice renvoie un paquet indiquant qu'elle a pris en compte la rponse postive de l'autre partie (tape 3), la connexion est alors tablie et les paquets de donnes "utiles" peuvent alors commencer circuler. La fermeture de la connexion, elle, s'effectue en 2 temps. Ce processus est lourd. Chaque connexion HTTP necssite une connexion TCP. Une page Web comportant 50 images et 10 fichiers javascripts ncessitera donc 61 connexions entre le client et le serveur. Une telle page web peut alors mettre un certain temps avant d'arriver "entire" jusqu'au client, qui peut vite avoir une impression de ralentissement trs dsagrable. Pour pallier ce problme, HTTP utilise des mcanismes pour grer, piloter et commander la connexion entre les 2 parties concernes (ou plus, si des proxies existent). Les connexions parallles, les connexions persistantes et le "pipelining".

XI-A - Connexions parallles


Pour assurer un meilleur traffic et une meilleure perception de fluidit sur le Web, les navigateurs peuvent envoyer plusieurs requtes simultanment sur plusieurs connexions TCP. On appelle cel les connexions parallles. L'erreur est de se dire tout de suite que ceci acclre les choses. Si vous avez bien suivi l'introduction de ce chapitre, vous savez qu'tablir une connexion TCP cote cher. Aussi, un serveur est limit en nombre total de connexions qu'il peut traiter, il y a un risque de le saturer. Enfin, les connexions parallles ne sont efficaces et avantageuses que si la bande passante le permet : un client surfant avec un modem bas dbit va saturer probablement une des connexions parallles, plus lourde que les autres (une trs grosse image), laissant ainsi les autres avec trs peu de bande passante disponible : elles deviennent alors inefficaces, voire mme contre-efficaces, lorsqu'on sait que TCP emet des paquets de contrle entre chaque paquet de donnes. Il faut donc utiliser un nombre de connexions restreint (Firefox 3 propose 15 par dfaut), et utiliser une connexion large bande, sinon l'efficacit ne sera pas au rendez-vous. Firefox permet de modifier le nombre de connexions via ses paramtres network.http.maxconnections et network.http.max-connections-per-server.

XI-B - Connexions persistantes


Les connexions persistantes n'ont rien voir avec les connexions parallles vues juste avant. Elles permettent au serveur de ne pas fermer la connexion TCP ds que la requte est termine. Le client pourra alors rutiliser la connexion sans devoir la re-ngocier. HTTP 1.0 ne supporte pas les connexions persistantes nativement, mais des extensions de la norme ont tout de mme rendu possible ce paradigme. Il est en HTTP 1.0 mal support, et peu efficace.

- 40 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

HTTP 1.1 introduit un changement fondamental dans la gestion des connexions entre le client et le serveur, puisqu'il dfinit et supporte clairement les connexions persistantes, mais en plus il fait de celles-l un standard utilis par dfaut. Sauf avis contraire, en HTTP 1.1, toute connexion est par dfaut persistante (cette caractristique t longuement dbattue l'poque). Au contraire avec HTTP 1.0, sauf si le serveur rpond avec un en-tte Connection: keep-alive et que le client a exprssement demand une connexion persistante avec le mme en-tte dans sa requte : la connexion est ferme par dfaut. Nous allons rester sur HTTP 1.1. Lorsqu'un client emet une requte, il sait que le serveur par dfaut ne fermera pas la connexion. Ainsi le client va pouvoir rutiliser celle-ci ds qu'elle est libre, pour envoyer une autre requte. A tout moment, le serveur comme le client peut rpondre par un en-tte Connection: close, ce qui aura pour but de fermer la connexion. Un client ne peut pas savoir si un serveur fermera un jour une connexion, c'est pour cel qu'un processus de r-emission de la requte est mis en place si la connexion venait tre ferme au moment prcis o le client tente d'envoyer une requte. Quoi qu'il en soit, toute connexion persistante est tout de mme ferme au bout d'un moment sinon le serveur peut arriver cours de connexions TCP et ne plus pouvoir rpondre. Apache propose pour la gestion des connexions, les directives KeepAliveTimeout, KeepAlive, Timeout et MaxKeepAliveRequests Il est impratif pour que les connexions persistantes puissent prendre place, de bien spcifier un en-tte ContentLength ou un Transfert-Encoding: chunked. Ceci va permettre aux 2 parties de faire la diffrence entre les parties de 2 requtes conscutives sur une mme connexion. L encore, un client devrait rester raisonnable et ne pas ouvrir trop de connexions persistantes afin d'viter que celle-ci ne restent en attente et non fermes. Il existe un en-tte permettant de dfinir les caractristiques de la connexion persistante, il s'agit de Keep-alive. Il peut prendre 2 valeurs (plus en ralit, mais les autres sont peu importants). timeout va indiquer combien de temps la connexion va tre maintenue dans un tat de sommeil. max prcise combien de requtes peuvent encore tre envoyes sur cette connexion avant qu'elle ne soit ferme. Attention, ces indications ne sont en aucun cas des garanties, et un serveur pourra changer d'avis (notamment dans le cas ou il arrive au bord de la saturation). L'en-tte de rponse Keep-alive n'est pas dfinit dans HTTP 1.1, mais dans HTTP 1.0. Il est cependant prcis dans HTTP 1.1 la plupart du temps, tout comme la plupart des navigateurs webs prcisent connection:keep-alive en HTTP 1.1 alors que ceci n'est pas ncessaire (compatibilit HTTP 1.0). Firefox permet de modifier le nombre de connexions persistantes par serveur via son paramtres network.http.max-persistent-connections-per-server. Pour aller plus loin, vous pouvez lire HTTP Performance du W3C ou encore HTTP Connection Management

XI-C - Pipelining
Le pipelining est une application des connexions persistantes. Cela consiste pour un client envoyer plusieurs requtes la suite dans la mme connexion, sans attendre la rponse entre chaque requte. Ceci vite encore quelques latences en vitant un "ping-pong" permanent entre le client et le serveur, mme si tout ceci se passe sur la mme connexion. Un client ne doit utiliser le pipelining que s'il est sr que la connexion est bien persistante. Aussi, le serveur doit envoyer ses rponses sur cette connexion dans le mme ordre que les requtes lui sont arrives, car il n'existe aucune numrotation ou trace des requtes dans une mme connexion.

- 41 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

XII - Les outils


HTTP est un protocole "human readable", il est donc possible d'agir dessus, et pourquoi pas d'crire sa syntaxe la main. Tous les navigateurs webs possdent une solide couche HTTP, voyez celle de Firefox par exemple. Bien sr, tous les serveurs webs aussi, voyez celle d'Apache par exemple. Mais en ralit, n'importe quel logiciel li un rseau TCP/IP peut communiquer via HTTP, sur le port 80, voyons quelques possibilits

XII-A - Les langages Web : PHP


PHP est un langage de script Web. Je ne vais pas le prsenter ;-). Voyons un peu comment on peut agir sur HTTP via PHP. Les fonctions suivantes jouent sur les en-ttes de la rponse du serveur, la liste n'est pas exhaustive : header() : permet de spcifier la main un en-tte de rponse et ventuellement de changer le code de rponse HTTP headers_sent() : indique si les en-ttes de la rponse ont dja t envoys au client ou pas setcookie() : envoie un en-tte Set-Cookie dans la rponse, peut aussi tre fait via header() session_start() : envoie des en-ttes pour la gestion de la session : cache, cookie, etc... headers_list() : rcupre la liste des en-ttes envoyer dans la rponse courante apache_response_headers() : rcupre la liste des en-ttes envoyer dans la rponse courante, plus prcise que headers_list(), mais ncessite de tourner sous module apache get_headers() : rcupre les en-ttes de la rponse une requte fournie ext/http est trs

PHP dispose aussi d'extensions permettant de manipuler HTTP de manire trs complte, puissante.

Des frameworks proposent aussi de manipuler HTTP via des objets PHP, c'est le cas de Zend_Http par exemple. Enfin, PHP pouvant ouvrir une socket rseau, il peut tout fait ( plus bas niveau donc), crire un code HTTP et attendre la rponse de la socket. Avec ces outils et la maitrise du protocole HTTP, il est possible de crer des programmes de toutes sortes : robots indexeurs, serveurs webs (oui oui, on en trouve des "persos" en python, en C, en PHP... ), mais aussi des outils relatifs la scurit, qui cherchent des failles dans les formulaires en sniffant la source HTML et en injectant des paramtres dans les formulaires ou les requtes GET. Je ne vais pas m'tendre, mais on peut aller beaucoup plus loin. Il est clair et net que lorsqu'on maitrise HTTP, on ne regarde plus du tout le web de la mme manire, et on s'aperoit du nombre combien important de serveurs et de sites bourrs de failles de scurit, en grande partie parce que leurs administrateurs ou leurs dveloppeurs n'ont aucune ou trs peu de notions de HTTP. Vraiment trange lorsqu'on sait que tous les travaux sur HTTP sont en ligne, il existe des ouvrages trs bons ainsi que des tutoriaux ;-)

XII-B - Telnet
La commande Unix Telnet est trs pratique puisqu'elle permet d'crire soit mme la main, octet par octet, des instructions HTTP sur un serveur. Rien de mieux pour tester son serveur, mme si c'est souvent long d'crire toutes les lignes. Telnet vous permet d'crire directement du code dans une socket connecte via TCP.

XII-C - Wget
Les puristes Linux peuvent passer leur chemin, je ne leur apprendrai rien ici :-D. Wget est une commande qui peut aussi tre utilise pour se connecter un serveur via HTTP.

- 42 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

XII-D - Curl XII-E - Outils webs


Rex Swain's HTTP Viewer Askapache headers tool Proxy HTTP Charles Proxy HTTP Nginx Web-sniffer HTTP Debugger Fiddler

Firefox propose tout un tas d'extensions permettant de "jouer" avec HTTP, les cookies, les donnes envoyes, le referer, etc... Firebug AddNEditCookie FireCookie HttpFox LiveHTTPHeaders UseragentSwitcher HeaderMonitor TamperData Refspoof

- 43 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

XIII - Au del du Web avec HTTP


HTTP n'est pas limit au Web dans le sens "je consulte une page HTML de l'Internet". Aujourd'hui, les services Webs utilisent HTTP pour transporter de l'information. En fait, vous avez vu dans cet article le potentiel de HTTP, et je pense que vous vous tes rendu compte que oui : il s'agit d'un protocole de la couche OSI "applicatif" : il peut transporter peu prs toute sorte d'information. Prenons SOAP par exemple. Ce protocole dcrivant des services Web est en fait une surcouche de HTTP qui utilise uniquement la mthode POST et des descriptions XML pour effectuer du RPC (appels de procdures distantes). D'un point de vue HTTP, rien n'est mieux que REST. Les services webs dits "RESTFul" tirent vraiment partie de HTTP : il ne sert rien de rinventer la roue (rinventer un protocole), alors que HTTP est l. Connaissez-vous des projets comme Apache CouchDB ? Non ? Regardez plutt. Il s'agit de services REST avec rponses JSON qui exploitent une fois de plus une grande partie des capacits de HTTP. ATOM, cel vous dit-il quelque chose ? Non ? Oulala, courrez voir ce protocole de liaison de donnes entirement bti sur HTTP, d'une beaut comparable celle de REST ! On pourrait aussi citer la surcouche protocolaire WebDav, et plus encore...

- 44 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

HTTP : le protocole du Web pass en revue par Julien Pauli (Tutoriels, article et confrences PHP et developpement web) (Blog)

XIV - Rfrences
LA page officielle de HTTP, qui retrace toute son histoire et ses volutions : http://www.w3.org/Protocols/ Schma de

Firefox networking performance (about:config) IBM Software information server HTTP dcision HTTP dans le traitement d'une requte (trs bien fait)

- 45 Copyright 2009 - Julien PAULI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' 3 ans de prison et jusqu' 300 000 E de dommages et intrts.
http://julien-pauli.developpez.com/tutoriels/web/http/

Vous aimerez peut-être aussi