Blesse moi avec la vérité ne ne ménage pas avec un mensonge...

Chaque personne aime une musique spécifique, dans laquelle se reflète son niveau de conscience et sa psychologie particulière. Nous pouvons observer ce que provoque en nous chaque musique, se demander pourquoi, et si ce que nous sentons est ce que nous cherchons dans la vie.

Le HTTP

                                       DEFINITION DE HTTP

L'Hyper-Text Transfer Protocol, plus connu sous HTTP littéralement « protocole de transfert hypertexte »  est un protocole de communication client-serveur développé pour le web. HTTPS (avec S pour secured, soit « sécurisé ») est la variante du HTTP sécurisée par l'usage des protocoles SSL ou TLS.

HTTP est un protocole de la couche applicative(couche 7 du modèle osi ou 4 du tcp). Il peut fonctionner sur n'importe quelle connexion fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par défaut le port 80 (443 pour HTTPS).

Les clients HTTP les plus connus sont les navigateurs Web permettant à un utilisateur d'accéder à un serveur contenant les données. Il existe aussi des systèmes pour récupérer automatiquement le contenu d'un site tel que les aspirateurs de site Web ou les robots d'indexation.

Ces clients se connectent à des serveurs HTTP tels qu'Apache HTTP Server ou Internet Information Services.

                               HISTORIQUE DE HTTP

HTTP a été inventé par Tim Berners-Lee avec les adresses Web et le langage HTML pour créer le World Wide Web. À cette époque, le File Transfer Protocol (FTP) était déjà disponible pour transférer des fichiers, mais il ne supportait pas la notion de format de données telle qu'introduite par Multipurpose Internet Mail Extensions (MIME). La première version de HTTP était très élémentaire, mais prévoyait déjà le support d'en-têtes MIME pour décrire les données transmises. Cette première version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.

En mai 1996, HTTP/1.0 voit le jour et est décrit dans la RFC 1945. Cette version supporte les serveurs HTTP virtuels, la gestion de cache et l'identification.

En janvier 1997, HTTP/1.1 devient finalement standard de l'IETF. Il est décrit dans la RFC 2068 de l'IETF, puis dans la RFC 2616 en juin 1999. Cette version ajoute le support du transfert en pipeline (ou pipelinage) et la négociation de type de contenu (format de données, langue).

Méthodes

Dans le protocole HTTP, une méthode est une Commande spécifiant un type de requête, c'est-à-dire qu'elle demande au serveur d'effectuer une action. En général l'action concerne une ressource identifiée par l'URL qui suit le nom de la méthode.

Dans l'illustration ci-contre, une requête GET est envoyée pour récupérer la page d'accueil du site web www.perdu.com :

GET / HTTP/1.1

Host: www.perdu.com

Il existe de nombreuses méthodes, les plus courantes étant GET, HEAD et POST :

GET

C'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet.

HEAD

Cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même.

POST

Cette méthode est utilisée pour transmettre des données en vue d'un traitement à une ressource (le plus souvent depuis un formulaire HTML). L'URI fournie est l'URI d'une ressource à laquelle s'appliqueront les données envoyées. Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP (pour Ajax) par certains navigateurs (et la norme HTML qui ne supporte que les méthodes GET et POST pour les formulaires), cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée pour la mise à jour de ressources.

OPTIONS

Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général.

CONNECT

Cette méthode permet d'utiliser un proxy comme un tunnel de communication.

TRACE

Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.

PUT

Cette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question.

PATCH

cette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource.

DELETE

Cette méthode permet de supprimer une ressource du serveur.

Ces 3 dernières méthodes nécessitent généralement un accès privilégié.

Certains serveurs autorisent d'autres méthodes de gestion de leurs ressources (par exemple WebDAV).

Les intermédiaires du client au serveur

La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais :

• Un proxy (ou serveur mandataire) peut modifier les réponses et requêtes qu'il reçoit et peut gérer un cache des ressources demandées.
• Une passerelle (ou gateway) est un intermédiaire modifiant le protocole utilisé.
• Un tunnel transmet les requêtes et les réponses sans aucune modification, ni mise en cache.

                                          

Les différentes versions de http

HTTP 0.9

Au début du World Wide Web, il était prévu d'ajouter au protocole HTTP des capacités de négociation de contenu, en s'inspirant notamment de MIME. En attendant, le protocole HTTP 0.9 était extrêmement simple.

1. connexion du client HTTP
2. envoi d'une requête de méthode GET
3. réponse du serveur HTTP
4. le serveur ferme la connexion pour signaler la fin de la réponse.

Requête :

GET /page.html

La méthode GET est la seule possible. Le serveur reconnaît qu'il a affaire à une requête HTTP 0.9 au fait que la version n'est pas précisée suite à l'URI.

Réponse :

<HTML>

<HEAD>

<TITLE>Exemple</TITLE>

</HEAD>

<BODY>

<P>Ceci est une page d'exemple.</P>

</BODY>

</HTML>

Pour répondre à une requête HTTP 0.9, le serveur envoie directement le contenu de la réponse, sans méta-données. Il ne doit jamais se comporter ainsi pour les requêtes HTTP de version supérieure.

Inutile de chercher les versions inférieures à 0.9 du protocole HTTP : elles n'existent pas, car HTTP 0.9 n'avait initialement pas de numéro de version. Il a fallu lui en attribuer un quand HTTP 1.0 est arrivé.

HTTP 1.0

Le protocole HTTP 1.0, décrit dans le RFC 1945, prévoit l'utilisation d'en-têtes spécifiés dans le RFC 822. La gestion de la connexion reste identique à HTTP 0.9 : le client établit la connexion, envoie une requête, le serveur répond et ferme immédiatement la connexion.

Une requête HTTP présente le format suivant :

     Ligne de requête (Méthode, URL, Version de protocole)

     En-tête de requête

     [Ligne vide]

     Corps de requête

Les réponses HTTP présentent le format suivant :

     Ligne de statut (Version, Code-réponse, Texte-réponse)

     En-tête de réponse

     [Ligne vide]

     Corps de réponse

Requête :

GET /page.html HTTP/1.0

Host: example.com

Referer: http://example.com/

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

La version du protocole HTTP est précisée suite à l'URI. La requête doit être terminée par un double retour à la ligne (CRLF). HTTP 1.0 supporte aussi les méthodes HEAD et POST. On constate l'usage d'en-têtes inspirés de MIME pour transférer les méta-données :

Host

Permet de préciser le site web concerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la même adresse IP (name based virtual host, hôte virtuel basé sur le nom). C'est le seul en-tête réellement important.

Referer

Indique l'URI du document qui a donné un lien sur la ressource demandée. Cet en-tête permet aux webmasters d'observer d'où viennent les visiteurs.

User-Agent

Indique le logiciel utilisé pour se connecter. Il s'agit généralement d'un navigateur Web .

Réponse :

HTTP/1.0 200 OK

Date: Fri, 31 Dec 1999 23:59:59 GMT

Server: Apache/0.8.4

Content-Type: text/html

Content-Length: 59

Expires: Sat, 01 Jan 2000 00:59:59 GMT

Last-modified: Fri, 09 Aug 1996 14:21:40 GMT

<TITLE>Exemple</TITLE>

<P>Ceci est une page d'exemple.</P>

La première ligne donne le code de statut HTTP (200 dans ce cas).

Date

Moment auquel le message est généré.

Server

Indique quel modèle de serveur HTTP répond à la requête.

Content-Type

Indique le type MIME de la ressource.

Content-Length

Indique la taille en octets de la ressource.

Expires

Indique le moment après lequel la ressource devrait être considérée obsolète ; permet aux navigateurs Web de déterminer jusqu'à quand garder la ressource en mémoire cache.

Last-Modified

Indique la date de dernière modification de la ressource demandée.

HTTP 1.1

Le protocole HTTP 1.1 est décrit par le RFC 2616 qui rend le RFC 2068 obsolète. La différence avec HTTP 1.0 est une meilleure gestion du cache. L'en-tête Host devient obligatoire dans les requêtes.

Les soucis majeurs des deux premières versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'établissement d'une connexion TCP prend un temps triple de la latence entre client et serveur). Des expérimentations de connexions persistantes ont cependant été effectuées avec HTTP 1.0 (notamment par l'emploi de l'en-tête Connection: Keep-Alive), mais cela n'a été définitivement mis au point qu'avec HTTP 1.1.

Par défaut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête. On appelle souvent cette fonctionnalité keep-alive. Il est aussi permis à un client HTTP d'envoyer plusieurs requêtes sur la même connexion sans attendre les réponses. On appelle cette fonctionnalité pipelining. La persistance des connexions permet d'accélérer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du réseau.

La gestion de la persistance d'une connexion est gérée par l'en-tête Connection.

HTTP 1.1 supporte la négociation de contenu. Un client HTTP 1.1 peut accompagner la requête pour une ressource d'en-têtes indiquant quels sont les langues et formats de données préférés. Il s'agit des en-têtes dont le nom commence par Accept-.

Les en-têtes supplémentaires supportés par HTTP 1.1 sont :

Connection

Cet en-tête peut être envoyé par le client ou le serveur et contient une liste de noms spécifiant les options à utiliser avec la connexion actuelle. Si une option possède des paramètres ceux-ci sont spécifiés par l'en-tête portant le même nom que l'option (Keep-Alive par exemple, pour spécifier le nombre maximum de requêtes par connexion). Le nom close est réservé pour spécifier que la connexion doit être fermée après traitement de la requête en cours.

Accept

Cet en-tête liste les types MIME de contenu acceptés par le client. Le caractère étoile * peut servir à spécifier tous les types / sous-types.

Accept-Charset

Spécifie les encodages de caractères acceptés.

Accept-Language

Spécifie les langues acceptées.

L'ordre de préférence de chaque option (type, encodage ou langue) est spécifié par le paramètre optionnel q contenant une valeur décimale entre 0 (inacceptable) et 1 (acceptable) inclus (3 décimales maximum après la virgule), valant 1 par défaut.

Le support des connexions persistantes doit également fonctionner dans les cas où la taille de la ressource n'est pas connue d'avance (ressource générée dynamiquement par le serveur, flux externe au serveur, …)

 Les codes de réponses en HTTP

                                                 

On distingue 5 types de codes de réponse en HTTP

1xx Information

2xx Succès

3xx Redirection

4xx Erreur client

5xx Erreur Serveur

 1xx Les codes d'information 

Les codes d'information ont été introduits par HTTP 1.1 ;Ce sont:

.100 - Continue

.101 - Switching Protocols

Les codes en 2xx-Succès

 Les codes 2xx signifient que le serveur "a réussi à faire ce qu'on lui a demandé".

.200-OK

.201-Created

.202-Accepted

.203-Non authoritative information

.204-No Content

.205-Reset Content

.206-Partial Content

     

                                                      

                                               Les codes en 3xx-Rédirection

 Les codes 3xx définissent des contextes de redirection, ils sont donc souvent (voire obligatoirement pour certains) accompagnés d'un en-tête Location indiquant l'URL que le client va devoir suivre.Ce sont:

.300-Multiple Choices

.301-Permanenty redirect

.302-Found

.303-See Other

.304-Not Modified

.305-Use Proxy

.307.Temporary redirect

                                           Les codes en 4xx-Erreurs Clients

Le client est le bout du tunnel qui initie la connexion et envoie la requête HTTP. Si celle-ci est mal formée ou non comprise par le serveur, alors il s'agit d'une erreur du client et un code 4xx sera renvoyé par le serveur indiquant le type d'erreur que le client a faite.Ce sont:

.400-Bad Request

.401-Unauthorized

.402-Payment Required

.403-Forbidden

.404-Not Found

.405-Method Not Allowed

.406-Not Acceptable

.407-Proxy Authorization Required

.408-Request Timeout

.409-Conflict

.410-Gone

.411-Lengh Required

.412-Precondition Failed

.413- Request URI Entity Large

.414-Request URI Too Long

.415-Unsupported Media Type

                                  Les codes en 5xx-Erreurs Serveur

Il peut arriver que le serveur ait validé la requête du client, la comprenne, mais n'arrive pas à la traiter pour une raison diverse. un code 5xx sera alors renvoyé.Ce sont :

.500-Internal Server Error

.501-Not Implemented

.501-Bad Gateway

.503-Service Unavailable

.504-Gateway Timeout

.505-HTTP Version Not Supported

Il est aujourd'hui indispensable pour tout technicien du web de maitriser HTTP. C'est un protocole possédant quelques

astuces, mais qui demeure simple par rapport aux protocoles des couches OSI du dessous (TCP, IP, Ethernet ...).

Tout professionnel du web devrait connaitre ces notions, faire l'impasse dessus est grave et mènera à une mauvaise

utilisation du média ou des comportements incompris ou non valides. Connaissez-vous un mécanicien ignorant le

fonctionnement du moteur à explosions... ?