Technologie Internet - Université de Genève, CUI ©

Les grandes lignes du protocole HTTP

• la version actuellement la plus répandue est la version 1.0 (RFC 1945): HTTP: A protocol for networked information
• problèmes principaux de la version 1.0
  • l'utilisation du standard MIME est suffisamment proche de celle de HTTP, tout en étant suffisamment différente, pour provoquer une confusion même chez des spécialistes
  • analyse (parsing) lente, impossibilité de connaître la longueur d'une requête ou d'une réponse avant de l'avoir analysé
  • une connexion par URL
  • taille moyenne d'une réponse à un GET ~quelques kilobytes
  • problème de "foule soudaine" (flash crowd) pour certains sites à succès
  • la fermeture de la connexion après chaque document provoque la perte des informations de congestion
  • médiocrité des performances à cause du mécanisme de "slow-start"
  • l'ouverture de plusieurs connexions simultanées accélère l'affichage d'un document, mais congestionne le serveur avec des ouvertures simultanées.
• la version en cours de standardisation est la version 1.1 (RFC 2616) :
  • le but de la nouvelle version est de faire de HTTP un bon "citoyen" Internet et d'améliorer les performances, tout en restant compatible avec la version 1.0.
  • correction d'erreurs de la version 1.0
  • nouveautés:
    • le header Host: est maintenant obligatoire. Il désigne le nom de la machine à laquelle est destinée la requête. Cela permet d'avoir un serveur physique répondant à plusieurs noms virtuels comme si c'était des sites différents.
    • requêtes portant sur une portion de document
      • le client peut demander une partie d'un document (header Range:)
      • le serveur peut indiquer où la portion doit être insérée (header Content-Range:)
      • demande conditionnelle d'une portion (header If-Range:): si le document n'a pas été modifié depuis une certaine date, le serveur ne doit envoyer qu'une portion du document, sinon il doit envoyer la totalité (utile si le client a déjà une partie du document)
    • gestion de cache plus fiable pour améliorer l'utilisation de proxys
      • la requête doit contenir le header Host: <NomDeLaMachineDeDestination>
      • introduction du header Age: qui indique le temps total que le document a passé dans divers caches entre le serveur d'origine et le client + le temps de transit
      • permet un calcul plus précis d'une date d'expiration des copies du cache
      • le header Cache-Control: permet de restreindre la conservation d'une copie dans des caches intermédiaires. Fourni uniquement par le serveur contenant le document d'origine.
        • Public=cachable par tous.
        • Private=cachable uniquement par le client de l'utilisateur.
        • No-cache=interdit de cache,
        • No-store=interdit de mémoire non-volatile+à purger de la mémoire volatile aussi tôt que possible.
        • No-transform=interdit toute transformation d'un type de média vers un autre type de média, même si cela économiserait de la place. Normalement un cache peut décider d'envoyer un format de données en lieu et place d'un autre format de données.
        • Must-revalidate=vérifier auprès du serveur d'origine avant d'utiliser la copie d'un cache.
        • Proxy-revalidate=comme "must-revalidate", mais ne s'applique pas aux caches locaux.
        • max-age=<NbSecondes>=après le nombre de secondes indiquées un cache du document doit être considéré comme périmé. Combiné avec le header Age, il permet de déterminer la validité d'un document même en présence d'horloges non synchronisées (serveur proxys, client).
        • extensions possibles par "<symbole>=<valeur>"
      • le header Vary: permet d'indiquer, lors de négociation de contenu, quels headers de la requête ont été utilisés pour choisir la réponse envoyée. Cela permettra à un cache de déterminer, lors d'une nouvelle requête, si la version du cache peut être utilisée. En effet, la même URL peut correspondre à différents contenus, le header Vary indique donc quelles informations ont servi à la négociation de contenu.
      • la réponse à une requête peut contenir des avertissements (warnings) sur la réponse envoyée (response is stale, revalidation failed, disconnected operation, heuristic expiration, transformation applied)
      • les headers Proxy-Authenticate et Proxy-Authorization permettent une authentification hop par hop des intermédiaires utilisés lors d'un transfert.
    • connexions persistantes: le serveur ne referme plus systématiquement la connexion une fois qu'il a fini de transmettre la réponse à la requête, afin de permettre l'envoi de nouvelles requêtes qui seraient liées à la première réponse (par exemples des images qui seraient incluses dans un document HTML).
      • par défaut, les connections sont persistantes, mais le client aussi bien que le serveur peut notifier l'autre de son désir de fermer la connection à la fin de la transaction courante.
      • les requêtes et les réponses peuvent être enchaînées les unes après les autres, sans qu'il soit nécessaire de les sérialiser.
      • devrait avoir une bonne influence sur les temps de réponses et la charge du réseau.
      • remplace l'utilisation du header Keep-Alive: qui ne fonctionne pas bien en présence de proxys.
      • un header Transfer-Encoding: chunked a été introduit pour permettre de continuer à utiliser des connexions persistantes même quand certaines des ressources transmises sont produites dynamiquement, par ex. par des scripts CGI et que leur dimension n'est donc pas connue (impossibilité de fournir un header Content-Length). Lorsque ce header est utilisé, la ressource est envoyée par blocs précédés chacun de l'indication de la longueur du bloc. Un bloc vide (longueur 0) indiquera la fin de la ressource.
    • Compression pour économiser la bande passante:
      • un nouveau header Transfer-Encoding permet d'indiquer le type d'encodage utilisé à chaque étape (hop) du transfer d'une ressource
    • nouvelles méthodes:
      • OPTIONS: permet de déterminer quelles sont les possibilités offertes par le serveur, sans transférer de document.
      • TRACE: permet à un client de voir ce que reçoit le serveur, le serveur  (ou un cache intermédiaire) renvoie la requête reçue comme un document virtuel. Utilisée en conjonction avec les headers Via: et Max_Forwards:
    • quelques méthodes supprimées: CHECKOUT, SHOWMETHOD, LINK, UNLINK, CHECKIN, TEXTSEARCH, SPACEJUMP, SEARCH
    • autres nouveaux headers:
      • Upgrade: permet de passer à une version plus élevée du protocole au milieu d'une transaction.
      • Proxy-Authenticate:et Proxy-Authorization: permettent l'authentification du contenu des caches de proxys.
      • Content-Transfer-Encoding: permet la compression d'un contenu (requête ou réponse) entre deux intermédiaires se trouvant entre le client et le serveur d'origine.
      • Via: permet de voir le chemin suivi par une requête ou une réponse
      • ETag: permet au serveur d'attribuer un identificateur unique à la ressource envoyée. Cet identificateur pourra servir plus tard à vérifier si une copie (cache) est obsolète ou pas.
      • Expect: envoyé par le client utilisant les méthodes PUT ou POST pour indiquer la taille de ce qu'il va transmettre. Si le serveur renvoye le code 100 (Continue) le client peut transmettre la suite, sinon il évite d'envoyer inutilement quelque chose que sera refusé par le serveur.
    • nouveau mécanisme d'authentification "Digest":
      • devrait éliminer la transmission de mots de passe en clair. Basé sur le calcul d'un checksum à partir du username, du mot de passe, de la méthode HTTP, de l'URI et d'une valeur unique spécifique à la transaction.
    • nouveaux codes de status:
      • 100: autorise la suite d'un transfert
      • 206: contenu partiel
      • 300: choix multiples
      • 409: conflit
      • 410 (gone): indique que la ressource a définitivement été suprimée
• Introduit peu de temps après:
  • gestion d'états (mécanisme similaire aux "cookies" de Netscape): RFC 2965: HTTP State Management Mechanism
• relégué à plus tard:
  • calcul du nombre d'accès même à travers des caches (proxy), pour éviter le contournement des caches par les sites dont les revenus dépendent du nombre de visiteurs
  • négociation transparente de contenus
  • protocole d'extensibilité (PEP)

Il est à noter que, selon des études récentes, à l'heure actuelle (1999) seulement environ 60% des serveurs déclarant supporter HTTP1.1 surportent la spécification en totalité.

• version hypertexte du RFC 2616: HTTP1.1
• PRO-COW: Protocol Compliance on the Web, par Balachander Krishnamurthy et Martin Arlitt, AT&T Labs--Research Technical Memorandum #990803-05-TM
• HTTP 1.0 Logs Considered Harmful
• Key Differences between HTTP/1.0 and HTTP/1.1
• RFC 2145: Use and Interpretation of HTTP Version Numbers
• RFC 2227: Simple Hit-Metering and Usage-Limiting for HTTP
• RFC 2295: Transparent Content Negotiation in HTTP
• RFC 2964: Use of HTTP State Management
• Internet Draft: HTTP Trust Mechanism for State Management (March 4, 1998)
• Internet Draft: HTTP Extension Framework (March 15, 1999)
• HTTP/1.1 Performance Overview, W3C

Bertrand Ibrahim

Dernière modification: 1.12.00

Site Hosting: Bronco