Aller au contenu principal

6. Connection Management (Gestion des Connexions)

La transmission de messages HTTP est indépendante des protocoles de connexion de couche de transport ou de session sous-jacents. HTTP suppose uniquement un transport fiable pouvant fournir une livraison ordonnée des requêtes et des réponses.

6.1. Connection​

L'en-tête Connection permet à l'expéditeur de spécifier les options de contrôle souhaitées pour la connexion actuelle.

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (Établissement)​

Le client est responsable de l'établissement d'une connexion au serveur. HTTP n'a pas d'exigence de tramage de messages pour établir ou identifier la connexion elle-même.

6.3. Persistence (Persistance)​

HTTP/1.1 utilise par défaut des "connexions persistantes" (persistent connections), permettant d'envoyer plusieurs requêtes et réponses sur une seule connexion. Les implémentations HTTP DEVRAIENT prendre en charge les connexions persistantes.

6.3.1. Retrying Requests (Nouvelle Tentative de Requêtes)​

Lors de la nouvelle tentative automatique d'une requête, la connexion peut échouer pendant la transmission du message de requête (ou pendant l'attente du message de réponse). Un client NE DEVRAIT PAS automatiquement réessayer une requête à moins qu'il puisse confirmer que la requête est idempotente ([RFC7231], [Section 4.2.2]) ou qu'il reçoive un message du serveur d'origine indiquant que le serveur n'a pas traité la requête avant l'échec de la connexion.

6.3.2. Pipelining (Pipeline)​

Un client qui prend en charge les connexions persistantes PEUT envoyer plusieurs requêtes en "pipeline" (c'est-à-dire, envoyer plusieurs requêtes sans attendre chaque réponse). Un serveur DOIT envoyer ses réponses à ces requêtes en pipeline dans le même ordre que les requêtes ont été reçues.

6.4. Concurrency (Concurrence)​

Un client DEVRAIT limiter le nombre de connexions simultanées qu'il établit vers un serveur.

6.5. Failures and Timeouts (Échecs et Délais d'Attente)​

Les serveurs ont généralement une valeur de délai d'attente après laquelle ils ne maintiendront plus une connexion inactive. Les serveurs proxy peuvent utiliser des valeurs de délai d'attente plus courtes pour préserver les ressources.

6.6. Tear-down (Fermeture)​

L'en-tête Connection (Section 6.1) fournit une option de connexion "close" que l'expéditeur utilise pour signaler que la connexion sera fermée après l'achèvement de la requête/réponse actuelle.

6.6.1. Retrying Requests (Nouvelle Tentative de Requêtes)​

Un client DEVRAIT réessayer une requête idempotente si la connexion est fermée après l'envoi de la requête (même si le client avait envoyé des requêtes précédemment sur cette connexion).

6.6.2. Closure (Clôture)​

Lorsqu'un serveur effectue une fermeture immédiate d'une connexion TCP, il existe un risque important que le client ne puisse pas lire la dernière réponse HTTP.

6.7. Upgrade (Mise à Niveau)​

L'en-tête Upgrade fournit un mécanisme simple pour passer de HTTP/1.1 à d'autres protocoles incompatibles.

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Un serveur PEUT changer de protocole en envoyant une réponse 101 (Switching Protocols, Changement de Protocoles).

Dernière mise à jour le