En-tête de mise à niveau HTTP / 1.1 - HTTP/1.1 Upgrade header
| HTTP |
|---|
| Méthodes de demande |
| Champs d'en-tête |
| Codes d'état |
| Méthodes de contrôle d'accès de sécurité |
| Vulnérabilités de sécurité |
Le champ d'en- tête Upgrade est un champ d'en-tête HTTP introduit dans HTTP / 1.1 . Dans l'échange, le client commence par effectuer une requête en texte clair , qui est ensuite mise à niveau vers une version plus récente du protocole HTTP ou basculée vers un protocole différent. Une mise à niveau de connexion doit être demandée par le client; si le serveur souhaite appliquer une mise à niveau, il peut envoyer une 426 Upgrade Required réponse. Le client peut alors envoyer une nouvelle demande avec les en-têtes de mise à niveau appropriés tout en gardant la connexion ouverte.
Utiliser avec TLS
Une utilisation consiste à lancer une requête sur le port HTTP normal mais à basculer vers Transport Layer Security (TLS). En pratique, une telle utilisation est rare, HTTPS étant un moyen beaucoup plus courant d'initier un HTTP chiffré.
Le serveur renvoie un 426 code d'état pour alerter les clients hérités que l'échec était lié au client (les 400 codes de niveau indiquent un échec client).
Cette méthode pour établir une connexion sécurisée est avantageuse car elle:
- Ne nécessite pas de redirection d'URL désordonnée et problématique côté serveur;
- Permet l'hébergement virtuel de sites Web sécurisés (bien que HTTPS le permette également en utilisant l' indication du nom du serveur ); et
- Réduit le risque de confusion des utilisateurs en fournissant un moyen unique d'accéder à une ressource particulière.
Si les mêmes ressources sont disponibles à partir du serveur via à la fois des moyens sécurisés cryptés et des moyens clairs non cryptés, un homme du milieu peut maintenir une connexion non cryptée et non authentifiée avec le client tout en maintenant une connexion cryptée avec le serveur.
Les inconvénients de cette méthode comprennent:
- Le client ne peut pas spécifier l'exigence d'un HTTP sécurisé dans l'URI (bien que le client puisse l'exiger via la négociation de mise à niveau); et
- Puisque HTTP est défini sur une base de sauts , le tunnel HTTP peut être nécessaire pour contourner les serveurs proxy.
Utiliser avec WebSocket
WebSocket utilise également ce mécanisme pour établir une connexion avec un serveur HTTP d'une manière compatible. Le protocole WebSocket comporte deux parties: une poignée de main pour établir la connexion mise à niveau, puis le transfert de données proprement dit. Tout d'abord, un client demande une connexion WebSocket en utilisant les en Upgrade: WebSocket - Connection: Upgrade têtes et , ainsi que quelques en-têtes spécifiques au protocole pour établir la version utilisée et configurer une poignée de main. Le serveur, s'il prend en charge le protocole, répond avec les mêmes en Upgrade: WebSocket - Connection: Upgrade têtes et termine la négociation. Une fois la prise de contact terminée avec succès, le transfert de données commence.
Utiliser avec HTTP / 2
Le mécanisme de mise à niveau HTTP est utilisé pour établir HTTP / 2 à partir d'un simple HTTP. Le client démarre une connexion HTTP / 1.1 et envoie un en- Upgrade: h2c tête. Si le serveur prend en charge HTTP / 2, il répond avec le code d'état du protocole de commutation HTTP 101 . Le mécanisme de mise à niveau HTTP est utilisé uniquement pour HTTP2 (h2c) en texte clair. Dans le cas de HTTP2 sur TLS (h2), l' extension de protocole ALPN TLS est utilisée à la place.