Nouvelle page
{{Adsense dance}}
== Introduction ==
Sur l'Internet, de nombreux protocoles sont utilisés. Le protocole HTTP (HyperText Transfert Protocole) est l'un des plus courants. C'est notamment celui qui est utilisé pour la navigation sur les sites Web. Par exemple, si vous lisez la page http://www.microsoft.com, votre navigateur a eu recours au protocole HTTP pour récupérer la page Web, les différentes images, feuilles de styles, etc. Ce protocole est relativement simple dans sa forme. Je vous propose d'en étudier les différents aspects.
== Généralités ==
'''<u>Présentation </u>'''
Il s'agit d'un protocole reposant sur un unique échange initié par le client. Il est synchrone: le serveur ne peut commencer à répondre avant que le client ait fini d'envoyer la requête.
Il en existe trois versions: 0.9 (1991), 1.0 (février 1997) et 1.1 (octobre 2000). La version 0.9 est complètement obsolète et nous ne l'étudieront pas ici. De nos jours, la version 1.0 est très rarement utilisée; elle est d'ailleurs obsolète. Les principaux changements entre les versions 1.0 et 1.1 sont l'ajout de 2 types de requêtes ainsi que la possibilité d'héberger plusieurs sites Web sur un même serveur dans la version 1.1.
L'échange entre le client et le serveur se fait en mode texte. Le charset généralement utilisé est l'US-ASCII sur 8 bits. Il est cependant possible que cet encoding soit modifié selon le client ou le serveur.
'''<u>Historique </u>'''
Tim Berners-Lee travaille comme informaticien à l'Organisation européenne pour la recherche nucléaire (CERN) lorsqu'il propose, en 1989, de créer un système hypertexte distribué sur le réseau informatique pour que les collaborateurs puissent partager les informations au sein du CERN. Cette même année, les responsables du réseau du CERN décident d'utiliser le protocole de communication TCP/IP et le CERN ouvre sa première connexion extérieure avec Internet.
L'année suivante, l'ingénieur système Robert Cailliau se joint au projet d'hypertexte au CERN, immédiatement convaincu de son intérêt, et se consacre énergiquement à sa promotion. Tim Berners-Lee et Robert Cailliau sont reconnus comme les deux personnes à l'origine du World Wide Web.
Jusqu'en 1993, le web est essentiellement développé sous l'impulsion de Tim Berners-Lee et Robert Cailliau. Les choses changent avec l'apparition de NCSA Mosaic, un navigateur web développé par Eric Bina et Marc Andreessen au National Center for Supercomputing Applications (NCSA), dans l'Illinois. NCSA Mosaic jette les bases de l'interface graphique des navigateurs modernes et cause un accroissement exponentiel de la popularité du Web. Le NCSA produit également le NCSA HTTPd, un serveur HTTP qui évoluera en Apache HTTP Server, le serveur HTTP le plus utilisé depuis 1996.
En 1994, Netscape Communications Corporation est fondée avec une bonne partie de l'équipe de développement de NCSA Mosaic. Sorti fin 1994, Netscape Navigator supplante NCSA Mosaic en quelques mois.
En 1995, Microsoft essaie de concurrencer Internet avec The Microsoft Network (MSN) et échoue. Fin 1995, après la sortie de Windows 95 sans le moindre navigateur web préinstallé, Microsoft lance avec Internet Explorer la guerre des navigateurs contre Netscape Navigator.
'''<u>Structure</u>'''
Les requêtes et les réponses sont bâties sur le même modèle:
{Ligne d'introduction}{SEP}
{En-têtes séparées par des {SEP} }
{SEP}{SEP}
{Corps}
En théorie, le seul élément capable de différencier une requête d'une réponse, c'est la Ligne d'introduction. En fait, certaines en-têtes sont plutôt caractéristiques des requêtes, tandis que d'autres sont plutôt utilisées pour les réponses.
Les requêtes ont cette forme:
{Nom} {HSEP} {Valeur}
Le séparateur HSEP représente la combinaison deux points + espace '': ". Le protocole HTTP définit un ensemble d'en-têtes standard. Des en-têtes supplémentaires peuvent être ajoutées, à la condition que leur nom commence par "X_".
'''<u>Caractères Interdits ou Réservés</u>'''
{| class="wikitable" style="text-align:center; width:80%;"
|+ '''<span style="color: #000099;">Certains caractères sont interdits ou réservés à certains endroits du message</span>'''
|-
! scope=col | nom du caractère
! scope=col | code US-ASCII
! scope=col | notation courante
! scope=col | réserves et interdictions
|-
|retour chariot (Carriage Return, CR)
|OxOD (13)
|\r
|Il fait partie du séparateur
SEP.
Son utilisation à l'intérieur de la Ligne d'Introduction et des en-têtes est donc interdite.
|-
|nouvelle ligne (New Line ou Line Feed, LF)
|OxOA (10)
|\n
|Il fait partie du séparateur SEP. Son utilisation à l'intérieur de la Ligne d'Introduction et des en-têtes est donc interdite.
|-
|point d'interogation
|Ox3F (63)
|?
|Il est utilisé à certains endroits de la Ligne d'Introduction. Son utilisation à l'intérieur de celle-ci est donc réglementée.
|-
|égal
|Ox3D (31)
|=
|Il est utilisé à certains endroits de la Ligne d'Introduction. Son utilisation à l'intérieur de celle-ci est donc réglementée.
|-
|esperluette (et commercial)
|Ox26 (38)
|&
|Il est utilisé à certains endroits de la Ligne d'Introduction. Son utilisation à l'intérieur de celle-ci est donc réglementée.
|-
|dièse
|Ox23 (35)
|#
|Il est utilisé à certains endroits de la Ligne d'Introduction. Son utilisation à l'intérieur de celle-ci est donc réglementée.
|-
|pourcentage
|Ox25 (37)
|%
|Il est utilisé dans le cadre de l'URL-Encoding. Son utilisation à l'intérieur de celui-ci est donc réglementée.
|-
|deux points
|Ox3A (58)
|:
|Il sont utilisés dans les en-têtes. Son utilisation à l'intérieur de celles-ci est donc réglementée.
|-
|espace (Space, SP)
|Ox20 (32)
|' ' ou " "
|Il est utilisé dans la Ligne d'Introduction et les en-têtes. Son utilisation à l'intérieur de celles-ci est donc réglementée.
|}
''Le séparateur SEP correspond en fait au duo ''\rlnU (Carriage Return, New Line: CRLF)''
'''<u>L'URL-Encoding</u>'''
L'URL-Encoding permet d'insérer les caractères réservés, ou des caractères accentués, dans certaines parties des messages HTTP.
La règle est simple: on remplace le caractère par un «%» suivi de son code hexadécimal dans l'encodage courant du document (c'est-à-dire la norme iso-8859-1 en général pour l'Europe de l'Ouest et les Amériques). La table ci-dessous donne les plus importants d'entre eux pour nous autres français.
[http://univers-pc.fr/Upload/images/1272917083-lurl-encoding.jpg http://univers-pc.fr/Upload/miniatures/1272917083-lurl-encoding.jpg]
Pour décoder une chaîne URL-Encodée, il suffit de remplacer le triplet %?? par le caractère dont le code US-ASCII correspond.
'''<u>Site statique, semi-dynamique ou dynamique</u>'''
*Le site statique
- est composé de pages conçues à l'avance de manière définitive. Dans ce cas, le contenu des pages n'évoluera pas dynamiquement en fonction d'un choix de l'utilisateur. (Exemple : recette de cuisine, on n'y touche plus).
*Le site semi-dynamique
- est un site statique composé de pages conçues à l'avance mais enrichies par une base de données. Dans ce cas, le contenu des pages n'évoluera pas dynamiquement en fonction d'un choix de l'utilisateur. L'un des meilleurs exemples est un catalogue de pièces détachées.
*Le site dynamique
- est constitué de pages enrichies de données provenant d'une base de données. Il est nécessaire d'exécuter des traitements d'accès aux données sur le serveur permettant de constituer la page. Un bon exemple est votre site de gestion de vos comptes en ligne de votre banque ou un site de cours de bourse.
== L'échange HTTP ==
'''<u>Simple</u>'''
[http://univers-pc.fr/Upload/images/1272919302-echangehttpsimple.jpg http://univers-pc.fr/Upload/miniatures/1272919302-echangehttpsimple.jpg]
'''<u>Complet</u>'''
[http://univers-pc.fr/Upload/images/1272919347-echangehttpcomplet.jpg http://univers-pc.fr/Upload/miniatures/1272919347-echangehttpcomplet.jpg]
'''<u>LES URL </u>'''
Le concept du WEB est de permettre l'accès à des documents reliés entre eux et dispersés sur des milliers de machines réparties sur la planète. Au départ, l'idée était de relier des documents texte; on dit que l'on utilise une technique d'hypertexte. Mais maintenant, on trouve de plus en plus d'images, de sons, de vidéos, ... On parle alors d'hypermédia.
D'un point de vue technique, les fondements du WEB sont simples. Il s'agit de permettre l'accès, au moyen d'un système client-serveur, à des documents hypermédia distribués!
Dés le moment où l'on a imaginé le WEB, on a dû concevoir un mécanisme de nommage et de localisation des documents (appelé URL : Uniform Resource Locator), permettant d'identifier individuellement les différents documents accessibles à travers le WEB. Les documents hypermédia présents sur le WEB sont écrits à l'aide du langage HTML (HyperText Markup Language). Il s'agit de simples textes (ASCII) auxquels on a ajouté des constructions spéciales qui permettent de définir en particulier les liens vers d'autres documents au moyen des URLs.
Une URL est de la forme suivante:
protocole: / / serveur : port / chemin / fichier # position
{| class="wikitable" style="text-align:center; width:80%;"
|+
|-
! scope=row | protocole
|Le nom du protocole: le plus souvent http.
|
|-
! scope=row | serveur
|Le nom d'une machine reliée à Internet ( www.toto.fr ) ou son adresse ( 128.178.50.32 ).
|-
! scope=row | [port]
|Le numéro de port sur lequel le serveur est en attente. Suivant le protocole utilisé, il existe toujours une valeur par défaut.
( 80 pour HTTP ).
|-
! scope=row | [chemin]
|Le chemin ( suite de répertoires séparés par des /) vers le document recherché.
|
|-
! scope=row | fichier
| Le nom du document recherché.
|
|-
! scope=row | [#position]
| Un nom désignant une position à l'intérieur du document.
|}
'''<u>Principe</u>'''
HTTP est un protocole transactionnel, simple, basé sur le principe de Requête/Réponse. Il est dit sans état:
le client envoie une requête et le serveur répond, indépendamment des requêtes précédentes et sans conserver la moindre information pour les requêtes à venir. Ensuite, il libère la connexion. Les serveurs peuvent cependant enregistrer les entêtes des requêtes à des fins statistiques et de déboggage.
HTTP n'est pas orienté session, il n'a aucun moyen d'identifier un utilisateur au cours d'une série de connexions à un site WEB.
Une transaction HTTP se décompose en quatre phases:
[http://univers-pc.fr/Upload/images/1273059203-transactionhttp01.jpg http://univers-pc.fr/Upload/miniatures/1273059203-transactionhttp01.jpg]
Remarque:
C'est le client qui ouvre la connexion, mais c'est le serveur qui la ferme. Une transaction HTTP correspond au transfert d'au plus une seule ressource. Ainsi, cela n'a pas de sens de dire que l'on est "connecté" à un site WEB. Les sites qui donnent à l'utilisateur l'illusion d'être connecté, utilisent entre autre, les cookies.
Exemple pour la transaction : http://www.didier.be/monrepertoire/mapage.html
Le navigateur analyse l'URL
Il demande au DNS l'adresse IP de la machine www.didier.be
Le DNS répond 85.119.245.11
Le navigateur établit une connexion TCP sur le port 80 à l'adresse 85.119.245.11
Il envoie alors la commande GET /monrepertoire/mapage.html
Le serveur www.didier.be envoie le fichier mapage.html
La connexion TCP est libérée par le serveur. La transaction est terminée.
Le navigateur interprète et affiche la page correspondante à mapage.html
Si il y trouve des références à des images, sons, etc ... , il va faire une nouvelle transaction pour chacune d'entre elles et réactualisera son affichage au fur et à mesure.
Il est important de noter que le navigateur doit établir une nouvelle connexion TCP pour charger chaque composant de la page en question, ce qui n'est franchement pas efficace dans le cas de documents contenant un grand nombre d'images. (Aujourd'hui, c'est pratiquement toujours le cas, mais les dernières versions du protocole apportent des solutions que l'on abordera plus loin). Parfois, le client demande au serveur un peu plus qu'un simple fichier: il peut lui demander d'exécuter un programme et de lui renvoyer le résultat. C'est ce qui se passe par exemple lorsque, après avoir rempli les champs d'un formulaire de recherche, l'utilisateur appuie sur le bouton [rechercher] du formulaire: les données du formulaire sont envoyées au serveur à l'aide de la requête, le serveur les communique au programme concerné, récupère les résultats et les retourne au client sous forme de réponse. Le mécanisme par lequel le serveur et un programme échangent des données en vue de construire un document à renvoyer au client est appelé CGI (Common Gateway Interface).
'''<u>Les Requêtes HTTP </u>'''
Dès que le client est connecté au serveur, il envoie sa requête. C'est en ce sens que l'échange est initié par le client.
Nous allons voir les spécificités des requêtes HTTP.
[http://univers-pc.fr/Upload/images/1273060314-lesrequeeteshttp01.jpg http://univers-pc.fr/Upload/miniatures/1273060314-lesrequeeteshttp01.jpg]
Comme précisé auparavant, le seul point qui change catégoriquement entre requête et réponse HTTP, c'est cette Ligne d'Introduction. Voici la forme qu'elle a pour une requête:
{Méthode} {sp} {Page} {SP} {Version}
Le séparateur SP correspond à l'espace.
'''<u>La Méthode</u>'''
GET
HEAD
POST
PUT
DELETE
OPTIONS
TRACE
CONNECT
On parle aussi parfois de type de requêtes.
Les Méthodes autres que '''GET''' et '''POST''' sont propres à la version 1.1 de HTTP.
Ces méthodes seront détaillées un peu plus loin.
'''<u>La Page </u>'''
Le spécificateur ''Page'' désigne le chemin vers la ressource chargée de traiter, ou de correspondre à la requête à partir de la racine du site.
Il doit commencer par un slash (/) et la chaîne doit être URL-Encodée.
Les paramètres d'URL (paramètres GET)
L'identificateur de fragment (fragment identifier')
Les paramètres d'URL sont indiqués avec cette syntaxe:
{Nom} {EQ} {Valeur}
Le ''Nom'' et la ''Valeur'' sont URL-Encodés. Forcément, il n'y a pas d'espace. Le séparateur EQ correspond au caractère égal.
Chaque paramètre est séparé du suivant par un esperluette (&).
La chaîne ainsi formée est placée à la suite du chemin, le tout étant séparé par un point d'interrogation.
Le fragment identifier permet de désigner une partie précise du document. " n'a pour le moment que peu (voire pas) de signification pour le serveur, car il est surtout utile au client. Par exemple, c'est lui qui est utilisé pour désigner une ancre dans un document HTML.
Le langage XPointer est prévu pour être notamment utilisé dans le fragment identifier.
Il doit également être URL-Encodé. " est ajouté à la suite des paramètres d'URL (ou du chemin s'il n'y a pas de paramètre d'URL) et il en est séparé par un dièse (#).
'''<u>La Version</u>'''
HTTP/1.0 pour la version 1.0
HTTP/1.1 pour la version 1.1
'''<u>Les Méthodes</u>'''
Nous allons maintenant voir un peu plus en détailles 4 méthodes proposées par la version 1.1 du protocole HTTP. Les informations sur les méthodes GET et POST sont également valables pour la version 1.0.
*GET
Cette méthode est la plus courante, il s'agit normalement d'une simple requête de téléchargement d'un document. Deux requêtes GET portant sur le même document devraient retourner des réponses sémantiquement identiques (certaines en-têtes pouvant influer sur le comportement du serveur, les réponses peuvent ne pas être totalement identiques). Aucune donnée à traiter ne peut être envoyée au serveur par cette méthode. Il est par contre possible d'ajouter les paramètres d'URL (aussi nommés paramètres GET). Le corps de la requête DOIT être vide, et le document spécifié dans la requête (la Page) est celui qui doit être retourné.
Exemple:
GET /search?p=protocole+HTTP+explication&ei=UTF-8&rd=r1 &fr=yfp-t-501 &xargs=0&pstart=1 &b=31 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Host: fr.search.yahoo.com:80
Connection: Keep-Alive
*HEAD
Cette méthode est similaire et presque équivalente à la méthode GET. C'est en fait la réponse finale du serveur qui est tronquée. La réponse à une requête HEAD est la réponse à la requête GET qui lui est similaire, sauf que le corps de la réponse HTTP n'est pas transmis. Cela permet souvent d'économiser beaucoup de bande passante.
*POST
La Méthode POST est la méthode de base pour demander un traitement d'informations au serveur. Ces requêtes sont censées mettre en jeu des mécanismes propres au serveur et provoquant des communications avec d'autres modules, voire d'autres serveurs, pour effectuer le traitement des dites données. De ce fait, il est tout à fait probable que deux requêtes POST identiques reçoivent des réponses différentes ou même sémantiquement opposées. Les données à traiter sont spécifiées dans le corps de la requête.
Le document désigné par la requête via la page est la ressource qui doit traiter les données et générer la réponse.
*PUT et DELETE
Ces méthodes sont censées permettre l'upload (le chargement sur le serveur) ou la suppression d'un document sans passer par un serveur FTP ou autre. Bien évidemment, cela peut provoquer des remplacements de fichiers, et donc de très grosses failles de sécurités sur un serveur. De ce fait, la plupart des serveur Webs requierent une configuration spéciale indiquant une ressource ou un document chargé de traiter ces requêtes. Le document désigné par la requête est celui qui doit être remplacé (ou créé), et le contenu du document est dans le corps de la requête. En théorie, les paramètres d'URL et le fragment identifier devraient être interdits ou ignorés par le serveur. En pratique, ils sont généralement transmis à la ressource chargée de traiter la requête.
*OPTIONS et TRACE
Ces méthodes permettent au client de demander certaines informations sur le serveur. Tous les serveurs ne les implémentent pas forcément.
*CONNECT
Cette méthode est censée être utilisée pour demander une utilisation du serveur en tant que proxy. Tous les serveurs ne les implémentent pas forcément.
'''<u>Les en-têtes de requête </u>'''
Nous allons ici présenter certaines en-têtes utilisées dans les requêtes HTTP. Elles ne sont pas forcément spécifiques aux requêtes, mais ont une signification particulière dans le cadre d'une requête.
*Host
Cette en-tête est la seule obligatoire pour les requêtes HTTP/1.1, c'est elle qui permet d'héberger plusieurs sites Web sur un même serveur. Sa valeur est le domaine du site Web. Elle est généralement spécifiée juste après la Ligne d'Introduction.
*User-Agent
Cette en-tête permet d'indiquer la signature du programme effectuant la requête. C'est une chaîne de caractères qui permet d'identifier le programme. En général, il s'agit du nom complet du programme et de sa version.
*Content-type et Content-Iength
Ces deux en-têtes ne peuvent être spécifiées que dans le cadre d'une requête POST ou PUT. Elles indiquent respectivement le type MIME et la taille en octets du corps de la requête. Si elles ne sont pas spécifiées, c'est le serveur qui est seul responsable de leur éventuelle valeur par défaut.
*Cookie
Cette en-tête permet au client de fournir un cookie au serveur. Sa valeur est simplement le nom et la valeur du cookie, séparés par un égal.
*D'autres en-têtes
De nombreuses autres en-têtes ont été prévues dans le protocole HTTP. Elles servent par exemple à préciser la gestion du cache, la langue ou le format préféré pour la réponse, l'authentification du client, etc. Les Requests For Comments (RFC) du protocole HTTP vous fourniront toutes les en-têtes [pour ses versions 1.0 et 1.1]. Toute en-tête non reconnue par le serveur doit théoriquement être ignorée.
'''<u>Le corps de la requête </u>'''
Le corps de la requête doit être vide pour les requêtes GET, HEAD, DELETE, CONNECT, TRACE et OPTIONS (dans le dernier cas, il est laissé éventuellement rempli pour de futures versions du protocole HTTP).
Dans le cas des requêtes POST et PUT, il correspond aux données à traiter. Il n'y a pas de caractères réservés ou interdits dans le corps de la requête au niveau du protocole HTTP. Cependant, les données doivent être conformes au format attendu par la ressource responsable de leur traitement.
== Les Réponses HTTP ==
Quand le serveur a fini de recevoir la requête, illa traite et renvoie la réponse appropriée (éventuellement une erreur).
Les réponses sont bâties sur un modèle similaire à celui des requêtes. Voyons leurs spécificités.
'''<u>La ligne d'Introduction</u>'''
Les lignes d'Introduction des réponses HTTP ont une structure plus simple que celle des requêtes, mais tout aussi riches en informations.
Le format est:
{Version}{SP}{Code Status}{SP} {Phrase Status}
La Version est la même que pour la requête.
Le Code Status est un code sur trois chiffres qui indique le status de la requête. Nous y reviendrons plus tard.
Le séparateur SP est un espace.
La Phrase Status est simplement une phrase permettant de rendre le status plus lisible pour un humain. Elle est purement indicative et n'a aucune valeur informative sur le plan du protocole, elle est d'ailleurs facultative. Nous indiquerons cependant les Phrases Status (Reason Phrase) proposées par les RFC pour les codes que nous détaillerons.
Les Codes Status sont regroupés en familles, qui sont au nombre de cinq pour les versions 1.0 et 1.1 de HTTP. La famille est indiquée par le premier chiffre du code (celui des centaines), il va de 1 à 5.
Tout code inconnu doit être traité par le client comme le code de base de la famille (XOO) et être présenté à l'utilisateur.
Si la famille est inconnue, le code doit être traité comme un code Erreur Serveur (famille 5xx) et être indiqué à l'utilisateur.
'''<u>Informations: les 1xx</u>'''
Ces codes sont là simplement pour permettre au serveur d'envoyer une notification.
*100 Continue
Ce code status est rarement utilisé et informe simplement que la partie de la requête qui a déjà été reçue est
valide. Il n'est pas envoyé par défaut, mais seulement dans des cas précis.
*101 Switching protocol
Ce code status permet de changer le protocole ou la version du protocole utilisé lors de la communication. Le
nouveau protocole à utiliser est spécifié par l'en-tête Upgrade.
'''<u>Succès: les 2xx </u>'''
Ces codes indiquent que tout s'est bien déroulé et que la ressource demandée est renvoyée.
*200 OK
Tout est bon, c'est la réponse la plus souvent employée.
*201 Created
Peut être utilisé par exemple dans le cadre d'un requête PUT pour indiquer que le document a bien été uploadé.
*204 No Content
La requête s'est bien déroulée, mais le corps de la réponse est vide.
*206 Partial Content
Ce code est généralement utilisé dans le cadre d'une récupération de téléchargement, ou de l'utilisation du cache. Seule une partie du document demandé est renvoyée.
'''<u>Redirection : les 3xx </u>'''
Ces codes indiquent que la ressource demandée n'est plus à l'emplacement indiqué. Ils sont très utilsés pour les redirections. L'en-tête, accompagnant la redirection et qui indique le nouvel emplacement de la ressource, est alors l'en-tête Location.
*300 Multiple Choice
Ce code est utilisé quand on peut trouver plusieurs versions de la ressource (différence de format ou de
langue par exemple).
*301 Moved Permanently
Quand une ressource est déplacée définitivement, c'est ce code qui permet d'indiquer le déplacement notamment aux moteurs de recherche. La requête ayant généré l'erreur doit alors être renvoyée pour correspondre avec la nouvelle ressource.
*307 Temporary Redirect
Ce code permet d'indiquer une redirection temporaire.
'''<u>Requête Invalide: les 4xx </u>'''
Ces codes indiquent une erreur de la part du client, ressource invalide, authentification invalide, etc. La requête doit alors être modifiée et éventuellement retransmise pour pouvoir être traitée.
*400 Bad Request
Erreur générique.
*401 Unauthorized ou Authorization required
Le client n'est pas censé avoir accès à la requête au vu de son niveau actuel d'identification. Il doit s'identifier de manière correcte. S'il ne peut remplir les conditions d'identification, alors les requêtes suivantes aboutiront à une erreur 403.
*403 Forbidden
La ressource est interdite au client.
*404 Not Found
La fameuse erreur 404, elle indique que la ressource demandée n'a pu être trouvée.
*405 Method Not Allowed
Le client n'est pas censé pouvoir envoyer ce type de requête, une authentification est certainement nécessaire.
'''<u>Erreur Serveur: les 5xx </u>'''
Ces codes sont utilisés en cas d'erreur de la part du serveur, en cas de surcharge, d'erreur de configuration, etc. Le plus simple est d'attendre un peu et de retenter plus tard: si l'erreur persiste, contactez l'administrateur du serveur.
*500 Internai Server Error
Erreur Interne au serveur, il n'est pas en état de répondre actuellement.
*501 Not Implemented
Certaines fonctionnalités requises par les en-têtes ou la méthode employées ne sont pas supportées par le serveur.
*503 Service Unavaible
Utilisé par exemple quand le serveur est surchargé.
*505 HTTP Version Not Supported
Le serveur ne supporte pas la version du protocole HTTP qui a été utilisée.
'''<u>D'autres codes status </u>'''
Tous les codes n'ont bien entendu pas été listés ici, certains ont même été invalidés lors du passage de HTTP/1.0 à HTTP/1.1 (306 par exemple), ou bien sont réservés pour des versions ultérieures du protocole (402 par exemple).
'''<u>Les en-têtes de réponse</u>'''
Voici les principales en-têtes utilisées lors des réponses.
*Content-type et Content-length
Ces deux en-têtes sont censées indiquer le type MIME et la taille en octets du corps de la réponse. De plus, l'en-tête Content-type peut indiquer le charset utilisé dans le corps de la réponse (dans le cadre d'un type texte). Il est alors indiqué par la mention "charset=" suivie du nom du charset. Il suit le type MIME, en est séparé par un point-virgule. Si elles ne sont pas indiquées, c'est le client qui est seul responsable de leur éventuelle valeur par défaut.
*Location
Cette en-tête permet d'indiquer une redirection. A sa réception, le client est généralement censé renvoyer une requête sur l'adresse indiquée. Ce comportement dépend du code status renvoyé avec la réponse.
*Set-Cookie
Cette en-tête permet d'indiquer au client des cookies à stocker. Sa valeur peut prendre une forme assez complexe. La forme par défaut est celle de l'en-tête de requête Cookie. Les formes plus évoluées consistent à l'indication d'informations telles que: la date de péremption (Expires), le domaine d'application (Domain), le chemin d'application (Path), etc. Toutes ces informations sont indiquées à la suite du couple nom/valeur de la même manière (nom de l'information, égal, valeur) et séparés entre elles et de celui-ci par un point-virgule.
*D'autres en-têtes
Bien sûr, toutes les en-têtes ne sont pas listées ici. Vous trouverez sûrement une description exhaustive dans la RFC ( RFC : Description complète du protocole)
== Pipelining HTTP ==
Le pipelining HTTP est une technique consistant à combiner plusieurs requêtes HTTP dans une seule connexion TCP sans attendre les réponses correspondant à chaque requête.
Le pipelining présente plusieurs avantages:
-amélioration importante du temps de chargement des pages, en particulier sur des liaisons présentant une forte latence
-réduction de la charge pour l'infrastructure réseau ainsi que pour les serveurs et clients HTTP Le pipelining nécessite, de la part du client aussi bien que du serveur, le support de la norme HTTP 1.1
telle que décrite dans la RFC 2616.
'''<u>Principe</u>'''
Dans la version 1.0 du protocole HTTP, le traitement des requêtes est séquentiel. Le client doit effectuer une nouvelle connexion TCP avec le serveur pour chaque objet (page, image, etc.) demandé et attendre le résultat avant de pouvoir poursuivre avec la requête suivante.
La technique du pipelining contourne ce problème en exploitant le principe de connexion persistante (keepalive). Lorsque le client envoie une requête HTTP au serveur, celui-ci inclut dans sa réponse la version du protocole HTTP utilisée. Si les deux extrémités utilisent HTTP 1.1, la connexion sera par défaut persistante. Le client doit indiquer qu'il souhaite fermer la connexion persistante avec le message "Connection: close" lorsqu'il ne souhaite plus utiliser la connexion.
Le pipelining peut alors prendre place sans autre négociation. Il consiste à envoyer plusieurs requêtes à la suite sans attendre leurs résultats. Le serveur HTTP a l'obligation de renvoyer les réponses exactement dans le même ordre que les requêtes.
On remarquera que puisqu'il est nécessaire qu'il y ait un échange complet entre client et Serveur pour s'assurer qu'ils supportent bien tous les deux HTTP 1.1, les requêtes constituant une nouvelle connexion ne peuvent pas être l'objet du pipelining. De même, seules les requêtes idempotentes[1]- telles que GET, HEAD, PUT et DELETE - peuvent faire l'objet du pipelining.
[http://univers-pc.fr/Upload/images/1273068002-pipelininghttp010001.jpg http://univers-pc.fr/Upload/miniatures/1273068002-pipelininghttp010001.jpg]
'''<u>Avantages</u>'''
L'utilisation du pipelining hérite plusieurs avantages de l'utilisation des connexions persistantes.
Ces avantages sont résumés dans la section 8.1.1 de la RFC 2616 décrivant le protocole HTTP 1.1. Notamment:
En ouvrant et fermant moins de connexions TCP, routeurs et hôtes (client, serveur, serveur mandataire, etc.) économisent du temps CPU. Les hôtes en particulier économisent la mémoire utilisée pour les blocs de contrôle TCP.
La congestion du réseau est diminuée par la réduction du nombre de paquets dus à l'ouverture de la connexion TCP, et par le fait qu'on laisse suffisamment de temps à TCP pour déterminer l'état de congestion du réseau.
La latence est réduite pour les requêtes suivantes puisqu'on ne perd pas de temps à cause de l'initialisation de la connexion TCP. De plus, en début de connexion, l'algorithme Slow Star! implique un débit plus réduit que pour une connexion établie.
L'avantage supplémentaire à l'utilisation du pipelining est qu'un client peut effectuer plusieurs requêtes sans attendre chaque réponse, permettant à une seule connexion TCP d'être utilisée avec plus d'efficacité, dans un temps plus court. Le concept est similaire aux mécanismes de fenêtre glissante dans TCP ou fenêtre d'anticipation dans HDLC.
== Divers ==
'''<u>Le cache: qu'est-ce que c'est? </u>'''
[http://univers-pc.fr/Upload/images/1273068453-cache01.jpg http://univers-pc.fr/Upload/miniatures/1273068453-cache01.jpg]
Afin de réduire la bande passante utilisée, le protocole HTTP met à disposition des clients le support d'un mécanisme de sauvegarde des données. Ainsi, sous certaines conditions, les clients sont autorisés à stocker les réponses du serveur afin de ne pas devoir redemander toute la page au serveur. Tout un ensemble d'en-têtes tant pour les requêtes que pour les réponses est dédié à cette gestion. De plus, le rôle de la méthode HEAD entre exclusivement dans ce cadre.
L'idée des caches est la même qu'en HTTP/1.0, mais le mécanisme a été beaucoup amélioré dans HTTP/1.1. L'objectif principal est la réduction du nombre de requêtes "inutiles" : éviter au maximum de faire des requêtes complètes et éviter de renvoyer des documents complets autant que possible.
Concrètement, le cache doit s'assurer au maximum de la "fraîcheur" des documents. Cela passe par l'utilisation de nouvelles directives et de nouveaux statuts. Le cache doit pouvoir gérer 2 choses: les directives du serveur ("ne conserve pas ce document" ... ) et les souhaits du client ("je ne garde pas les documents plus de tant de temps").
En fait, le type de requêtes reste le même, mais des algorithmes et des règles plus précis sur la façon de calculer et gérer l'âge des documents ainsi que les dates d'expiration ont été écrits. Tout ceci n'avait pas été fait dans HTTP/1.0 ou alors de façon trop imprécise.
'''<u>Les directives:</u>'''
HTTP/1.0 introduit des directives spéciales telles que Date, Expires et Last-Modified qui permettent de savoir quand le document demandé a été modifié depuis la dernière fois, ou de calculer le temps que doit rester une ressource dans le cache, voire tout simplement de dire à partir de quand on doit demander au serveur le nouveau document (directive Expires).
*La méthode HEAD:
La première idée pour savoir si une entité a été modifiée depuis la dernière fois a été d'utiliser une nouvelle méthode: la méthode HEAD. Cette méthode permet de ne récupérer que la partie en-tête d'un requête complète GET, ce qui permet par exemple d'obtenir la date de dernière modification (via les nouvelles directives) et donc de savoir si le document demandé a changé depuis la dernière fois, sans pour autant trop charger le réseau (le document ne voyage pas, seulement les méta-informations transitent).
*Le GET conditionnel:
HTTP/1.0 introduit un autre mécanisme de cache: une méthode GET conditionnel. Ceci se fait une fois de plus grâce à une nouvelle directive: If-Modified-Since. Le GET conditionnel permet de demander au serveur de renvoyer le document si et seulement si ce dernier a changé depuis la date indiquée en face de la directive. Pour le client, il suffit juste d'envoyer la date à laquelle il a reçu le document pour la dernière fois. Dans le cas où la ressource n'a pas été modifiée, le serveur renvoie un très court "HTTP/1.0 304 Not Modified" et le client sait alors qu'il n'a plus qu'a distribuer l'entité cachée.
*Entités non cachables:
Bien sûr, certains documents ne doivent pas être cachés (par exemple, les résultats renvoyés par des scripts CGI). Pour cela, on utilise encore une directive pragma : no-cache qui dit à tous ceux qui manipulent le document de ne pas le garder dans leur cache. L'autre solution est d'utiliser la directive Expires avec une date passée.
'''<u>Et PHP/ASP/JSP/ les CGI dans tout ça ? </u>'''
PHP, ASP, JSP et les CGI (aussi bien les scripts CGI et les CGI-bin) sont des langages ou des applications côté serveur, c'est le serveur et LUI SEUL qui se doit de les gérer. Il peut leur permettre d'interférer avec la réponse HTTP envoyée, via les headers ou le corps par exemple, mais cela relève de sa seule responsabilité et doit être transparent pour le client.
'''<u>Et (D)(X)HTML/JavaScript/ActiveX dans tout ça ? </u>'''
D)(X)HTML, JavaScript, ActiveX, CSS, etc. sont des langages ou des applications côté client, ils sont contenus dans le corps de la réponse HTTP et doivent être transparents pour le serveur. Ils ne peuvent normalement pas interférer avec le protocole HTTP puisqu'ils entrent en jeu après réception de la réponse par le client. Cependant, ils peuvent parfois interférer sur la création de la requête (formulaires (X)HTML) ou sur l'utilisation de l'échange HTTP (AJAX).
'''<u>MIME</u>'''
Multipurpose Internet Mail Extensions (MIME) est un standard internet qui étend le format de données pour supporter des textes en différents codage de caractères autres que l'ASCII, des contenus non textuels, des contenus multiples, et des informations d'en-tête en d'autres codages que l'ASCII.
Voir exemple avec CGI_Exemple.bat
'''<u>Une connexion = Un échange ?</u>'''
En théorie: OUI!
Ensuite, HTTP propose des mécanismes d'optimisation qui permettent de conserver la connexion entre le serveur et le client. Ainsi, nous pouvons charger des ressources annexes ou faire d'autres requêtes HTTP, car la mise en place d'une connexion est relativement coûteuse (surtout en temps d'exécution). Dans ce cas encore, ce sont des en-têtes spécifiques qui sont chargées de la gestion de cette connexion.
'''<u>Les cookies</u>'''
La gestion des cookies est assez complexe: Côté client, on peut, en théorie, y accéder en permanence puisque c'est là qu'ils sont stockés. Côté serveur, le comportement doit être étudié au cas par cas: configuration du client, configuration du serveur, langage utilisé côté serveur, configuration du module coté serveur sont autant de paramètres qui peuvent influer sur leurs réactions.
Le cookie est une technique qui consiste, pour un site WEB ou une page WEB, à enregistrer localement sur le poste client des informations utiles à la consultation dudit site ou de ladite page. En effet, la consultation WEB, effectuée grâce au protocole HTTP, ne permet pas nativement de garder des informations sur le contexte d'une session de travail sur un site WEB. Ainsi, lorsque vous êtes sur un site et que vous passez d'une page à l'autre en cliquant sur des liens, chaque requête est traitée de manière complètement indépendante, comme on l'a déjà vu plus haut. Pour pallier à cette non-persistance, on a donc introduit les cookies. En passant d'une page à l'autre sur un site, les premières pages peuvent déposer des informations sur le poste client à destination des pages visitées par la suite et donc recréer un mécanisme de session. Lorsque les informations à conserver sont nombreuses, le site WEB n'enregistre sur le poste client qu'un simple identifiant (un numéro unique lié à l'utilisateur). Les informations sont conservées alors localement sur une base, côté serveur, mais sont associées via l'identifiant contenu dans le cookie à l'utilisateur.
Les cookies sont apparus entre 1995 et 1996 à l'initiative de Netscape.
Les mécanismes de cookies utilisent le protocole HTTP pour fonctionner. Ils accompagnent les échanges en s'introduisant dans les entêtes HTIP des requêtes et des réponses. Toutes les spécifications concernant ces entêtes HTTP avec cookies sont contenues dans la (RFC2109 - HTTP State Management Mechanism).
'''<u>Voir le protocole HTTP</u>'''
[http://univers-pc.fr/Upload/images/1273070190-voirleprotocolehttp01.jpg http://univers-pc.fr/Upload/miniatures/1273070190-voirleprotocolehttp01.jpg]
*Utilisation du protocole
Si vous souhaitez tester le protocole HTTP par vous-même, vous pouvez utiliser telnet. Ce programme est disponible sur la plupart des plate-formes. Pour cela faites:
telnet {nom de domaine} 80
Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Elle comprend:
Une ligne de requête: c'est une ligne précisant le type de document demandé, la méthode qui doit être appliquée, et la version du protocole utilisée, La ligne comprend trois éléments devant être séparés par un espace:
La méthode
L'URL
La version du protocole utilisé par le client (généralement HTTP/1.0)
Les champs d'en-tête de la requête: il s'agit d'un ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la requête et/ou le client (Navigateur, système d'exploitation, ... ). Chacune de ces lignes est composée d'un nom qualifiant le type d'en-tête, suivi de deux points (:) et de la valeur de l'en-tête Le corps de la requête: c'est un ensemble de lignes optionnelles devant être séparées des lignes précédentes par une ligne vide et permettant par exemple un envoi de données par une commande POST lors de l'envoi de données au serveur par un formulaire.
Une requête HTTP a donc la syntaxe suivante (ccrlt> signifie retour chariot ou saut de ligne) :
METHODE URL VERSION<crlf>
EN-TETE: Valeur<crlf>
.
.
.
EN-TETE: Valeur<crlf>
Ligne vide<crlf>
CORPS DE LA REQUETE
Voici donc des exemples de requête HTTP :
*Exemple 1 avec GET
GET http://www.commentcamarche.net HTTP/1.0
Accept: text/html
If-Modified-Since: Saturday, 15-January-2000 14:37:11 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)
*Exemple 2 avec GET
telnet www.hobbesworld.com 80
GET /hobbesworld.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-
powerpoint, application/msword, */*
Accept-Language: fr
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 10.10.10.2
Connection: Keep-Alive
*Voir les réponses
Une réponse HTTP est un ensemble de lignes envoyées au navigateur par le serveur. Elle comprend:
Une ligne de statut: c'est une ligne précisant la version du protocole utilisé et l'état du traitement de la requête à l'aide d'un code et d'un texte explicatif. La ligne comprend trois éléments devant être séparés par un espace:
La version du protocole utilisé
Le code de statut
La signification du code
Les champs d'en-tête de la réponse: il s'agit d'un ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la réponse et/ou le serveur. Chacune de ces lignes est composée d'un nom qualifiant le type d'en-tête, suivi de deux points (:) et de la valeur de l'en-tête
Le corps de la réponse: il contient le document demandé
Une réponse HTTP a donc la syntaxe suivante (ccrlf> signifie retour chariot ou saut de ligne) :
VERSION-HTTP CODE EXPLICATION<crlf>
EN- TETE: Valeur<crlf>
EN-TETE: Valeur<crlf>
Ligne vide<crlf>
CORPS DE LA REPONSE
Voici donc les réponses HTTP des exemples de GET :
*Exemple 1 Réponse:
HTTP/1.0 200 OK
Date: Sat, 15 Jan 2000 14:37:12 GMT
Server : Microsoft-IIS/2.0
Content- Type: texUHTML
Content-Length : 1245
Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT
Le corps de la réponse (fait 1245 byte voir Content-Length)
*Exemple 2 Réponse:
HTTP/1.1 200 OK
Date: Wed, 03 Dec 2003 23:58:55 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Last-Modified: Wed, 03 Dec 2003 23:58:43 GMT
ETag: "9c1a4-74-413952cO"
Accept-Ranges: bytes
Content-Length: 116
Connection: close
Content-Type: texUhtml; charset=ISO-8859-1
<HTML>
<BODY>
ContenuHTML
</BODY>
</HTML>
*D'autres exemples
Exemple de GET en HTTP 1.1 avec envoi d'info
telnet www.hobbesworld.com 80
GET /cgi-bin/test.pl?testdata=Valeur HTTP/1.1
HOST: 10.10.10.2
HTTP/1.1 200 OK
Date: Wed, 03 Dec 2003 23:39:19 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Connection: close
Transfer-Encoding: chunked
Content-Type: texUhtml; charset=ISO-8859-1
<HTML>
<BODY>
contenu HTML testdata = Valeur
</BODY>
</HTML>
*Exemple de POST basic
telnet www.hobbesworld.com 80
POST /cgi-bin/test.pl HTTP/1.1
Host: 10.10.10.2
Content-Length: 37
testpost=hobbesworldcestjustepourvoir
HTTP/1.1 200 OK
Date: Wed, 03 Dec 2003 23:53:08 GMT
Server: Apache/2.0AO (Red Hat Linux)
Content-Length: 66
Connection: close
Content-Type: textlhtml; charset=ISO-8859-1
<HTML>
<BODY>
contenu HTML testdata = testpost=hobbesworldcestjustepourvoir
</BODY>
</HTML>
*Exemple de POST avec en-tête
telnet www.hobbesworld.com 80
POST /cgi-bin/test.pl HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-
powerpoint, application/msword, */*
Referer: http://10.10.10.2/test.html
Accept-Language: fr
Content- Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 10.10.10.2
Content-Length: 37
Connection: Keep-Alive
Cache-Control: no-cache
testpost=hobbesworldcestjustepourvoir
HTTP/1.1 200 OK
Date: Wed, 03 Dec 2003 23:54:46 GMT
Server: Apache/2.0AO (Red Hat Linux)
Content-Length: 66
Connection: close
Content- Type: textlhtm 1; charset=1 SO-8859-1
<HTML>
<BODY>
contenu HTML testdata = testpost=hobbesworldcestjustepourvoir
</BODY>
</HTML>
== Performance WEB ==
'''<u>Analyse d'une requête HTTP - serveur et réseau</u>'''
On parle de temps, de performance, mais finalement que mesure t-on ? La question n'est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?
Je vous propose un petit schéma incomplet des interactions lors de la requête d'une page HTML (attention, aucune échelle ou proportion n'est respectée).
[http://univers-pc.fr/Upload/images/1273071979-requetehtml01.jpg http://univers-pc.fr/Upload/miniatures/1273071979-requetehtml01.jpg]
*La requête DNS
Une fois que le visiteur clique sur un lien, c'est une requête DNS qui est lancée par le navigateur et environ 30ms qui sont perdues, parfois même jusqu'à 100 ou 150ms (triangle gris sur le schéma). Microsoft Internet Explorer 6 cache cette information pendant 30 minutes mais les autres navigateurs la relancent plus souvent. Mozilla Firefox ne garde le résultat de la requête DNS que pour une petite minute. Vous l'aurez donc quasiment à chaque nouvelle page. Vous pouvez réduire l'influence des requêtes DNS en limitant le nombre de domaines et sous-domaines utilisés par votre site. Gardez le nombre de domaines en dessous de quatre.
*La connexion au serveur
L'étape suivante c'est l'établissement de la connexion avec le serveur que vous souhaitez joindre (triangle vers sur le schéma). C'est assez rapide mais ça reste quelque chose qui va impacter les performances. Autorisez le keep-alive pour les ressources statiques (images, feuilles de styles, javascript) : Le navigateur et le serveur vont réutiliser la connexion existante au lieu de rétablir une nouvelle connexion pour chaque composant. Le gain est notable, j'en avais déjà parlé.
Maintenant le keep-alive c'est aussi ce qui va garder la connexion ouverte inutilement une fois que vous aurez téléchargé tous les composants. C'est le rectangle vert en bas sur le schéma. C'est coûteux pour vs serveurs. Désactivez donc le keep-alive sur le serveur qui renvoie les pages HTML, et réduisez la valeur pour les autres: cinq secondes sont bien suffisantes.
*La requête HTTP elle-même, et l'attente qui suit
Vient ensuite la requête HTTP elle-même (parallélogramme jaune sur le schéma). Vous voyez qu'elle prend un certain temps, symbolisée par une épaisseur sur le schéma. En cumulant toutes les entêtes et un cookie classique, votre requête peut facilement prendre 1 ko. Pensez donc à réduire la taille du cookie, et même à ne pas avoir de cookie pour les ressources statiques en les mettant sur un domaine tiers.
Par la suite, pour réduire l'influence des requêtes HTTP, il ne reste plus qu'à en faire moins. En fait c'est assez simple. Il suffit d'aggréger plusieurs fichiers en un seul, qu'on parle de CSS et javascript, ou de sprites pour les images. Vous épargnez le temps de faire la requête, mais aussi tout le temps d'attente du navigateur entre la fin de la requête et la réception de la réponse (espace blanc entre les parallélogrammes bleus et jaunes sur la ligne de temps du navigateur).
Une autre possibilité c'est d'envoyer plusieurs requêtes HTTP coup sur coup sans attendre les réponses. On utilise alors au mieux cet espace inutile entre la fin de la requête et le début de la réponse. On se permet même d'envoyer des donner dans un sens pendant qu'on en reçoit de l'autre côté, donc superposer des requêtes jaunes dans mon schéma avec des réponses bleues. C'est ce qui est réalisé avec le pipelining HTTP.
*Le calcul de la page par le serveur
Voilà la mesure du diable. Dès qu'on parle de performance tout le monde va vite mesurer ce temps de génération des pages, en mauve sur le schéma. Même si l'échelle et les proportions ne sont pas respectées sur le schéma, il est évident que cette mesure n'est vraiment pas la a seule, ni même la plus importante. Pour des pages bien faites et des serveurs qui ne sont pas surchargées, il est très rare d'avoir des pages qui prennent plus de 1 DOms pour le calcul serveur. C'est généralement dix fois moins, alors que le chargement complet de la page pour le visiteur prend lui plusieurs secondes.
Mais surtout, c'est l'étape qui est souvent la première à être optimisée, et celle où il est assez complexe de gagner encore des performances si on a déjà penser au cache. Ne vous focalisez pas sur le temps de génération des pages, sauf s'il est flagrant qu'il est disproportionné par rapport aux besoins.
Éventuellement, si votre page peut mettre longtemps à se générer et que c'est facile à faire, vous pouvez forcer un vidage du tampon au milieu de la génération de la page, pour que l'utilisateur commence à voir le contenu réel de la page et télécharge les composants tiers pendant que le calcul de la page continue à se faire. L'équipe Performance de Yahoo! en parle, l'équipe Search aurait eu de bons résultats avec cette technique.
*Le téléchargement de la page
La dernière étape du point de vue du serveur c'est le téléchargement de la page elle-même. C'est un des postes qui impactent le plus les performances. On a beau faire des publicités pour des liaisons à 24mb/s, si vous téléchargez une pages HTML à 2mb/s c'est bien. Et derrière si on compte les images, les cookies, les javascript, les feuilles de style, le flash, les vidéo, et la page HTML elle-même, ça prend du temps, incompressible.
Enfin certaines choses sont incompressibles, d'autres justement ... vous pouver minimiser les javascript et CSS, mais aussi utiliser la compression HTTP pour tout ce qui est fichier texte (HTML, javascript, CSS, XML, Json, etc.). Les résultats sont spectaculaires et il est facile de diviser le poids par dix, donc le temps de téléchargement d'autant.
On peut aussi faire bien mieux, et réduire tout le téléchargement de la page à quelques octets. " s'agit simplement de repérer quand le navigateur a déjà une page similaire en cache, et de lui répondre un code HTTP 304 "la page n'a pas changée". Ca fonctionne à base d'ETag, de date de modification et de requête conditionnelle HTTP.
*En attendant retenez:
Le début du rendu du navigateur ne correspond pas avec le début de la réception de la page HTML. La fin l'interprétation du HTML ne correspond pas du tout avec la fin de la réception de la page HTML. La fin du rendu total de la page peut intervenir plusieurs secondes après la fin de la réception de la page HTML. Mais de toutes façons le jeu c'est le plus possible d'éviter tout le schéma en lui même: réduire le nombre de requêtes HTTP, soit par une réduction du nombre de composants, soit par une exploitation au mieux du cache.
== Analyse des visites d'un site Web ==
Les serveurs web enregistrent la trace des visites dans des fichiers de log. Chaque requète (demande d'une page par un navigateur internet) génère une ligne dans un fichier de log. Ce fichier est utilisé par le webmaster pour déterminer quels sont les pages les plus visitées, combien de visiteurs passent sur le site, etc.
{{Sommaire|Logiciels reseaux|Logiciels reseaux}}
Commentaires récents
il y a 8 semaines 16 heures
il y a 9 semaines 2 jours
il y a 11 semaines 5 jours
il y a 11 semaines 5 jours
il y a 11 semaines 6 jours
il y a 11 semaines 6 jours
il y a 12 semaines 5 jours
il y a 14 semaines 17 heures
il y a 14 semaines 18 heures
il y a 14 semaines 5 jours