Question Nginx ignore la requête HTTP 1.0 du client et répond par HTTP 1.1


Je teste avec nginx/php5-fpm, avec le code

<?php

header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found"); 
// also tested: header("Status: 404 Not Found");

echo $_SERVER["SERVER_PROTOCOL"];

Et forcer à utiliser HTTP 1.0 avec le curl commander.

curl -0 -v 'http://www.example.com/test.php'


> GET /test.php HTTP/1.0

< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Sat, 27 Oct 2012 08:51:27 GMT
< Content-Type: text/html
< Connection: close
< 
* Closing connection #0
HTTP/1.0

Comme vous pouvez le constater, je demande déjà à utiliser HTTP 1.0, mais nginx me répond avec HTTP 1.1

Prime

@ MaximDounin, @ MichaelHampton a déjà fourni une réponse à la spécification, merci. J'étends un peu cette question pour le futur lecteur:

Q. Quels sont les avantages de répondre à HTTP 1.1 lorsqu'une demande client pour HTTP 1.0? L’approche adoptée par Google ne devrait-il pas être plus raisonnable, c’est-à-dire lorsque le client demande 1.0, répond avec 1.0?


7
2017-10-27 15:16


origine




Réponses:


Ceci est un comportement normal et attendu, selon RFC 2616:

Les applications qui sont au moins conditionnellement conformes à cette spécification DEVRAIENT utiliser une version HTTP de "HTTP / 1.1" dans leurs messages, et DOIVENT le faire pour tout message non compatible avec HTTP / 1.0. Pour plus d'informations sur l'envoi des valeurs HTTP-Version spécifiques, voir RFC 2145.

La RFC 2145 étend cette:

Un serveur HTTP DEVRAIT envoyer une version de réponse égale à la version la plus élevée pour laquelle le serveur est au moins partiellement conforme et dont la version principale est inférieure ou égale à celle reçue dans la demande. Un serveur HTTP NE DOIT PAS envoyer de version pour laquelle il n'est pas au moins conditionnellement conforme. Un serveur PEUT envoyer une réponse 505 (version HTTP non prise en charge) s'il est impossible d'envoyer une réponse à l'aide de la version principale utilisée dans la demande du client.

Un serveur HTTP PEUT envoyer une version à réponse inférieure, s'il est connu ou soupçonné que le client n'implémente pas correctement la spécification HTTP, mais cela ne devrait pas être la valeur par défaut et NE DEVRAIT PAS être fait si la version de la demande est HTTP / 1.1 ou supérieure.

Cela signifie en anglais: Si le client envoie une demande HTTP / 1.0, une réponse HTTP / 1.0 ou HTTP / 1.1 est acceptable, mais HTTP / 1.1 est préférable.

La raison en est que l’une des extrémités peut annoncer la version la plus élevée de HTTP qu’elle peut prendre en charge, de sorte que l’autre extrémité puisse choisir de mettre à niveau son support de protocole (si possible). Les deux extrémités décideront ensuite de la version du protocole avec laquelle elles peuvent vivre. Cette conception permet également de gérer les implémentations de bogues, comme indiqué dans la RFC 2145.

À l'époque, il était également envisagé de mettre en place d'autres versions du protocole HTTP, versions mineures et majeures, et les règles étaient censées contribuer à assurer l'interopérabilité. L'approche de Google ignorant les RFC peut ne plus fonctionner HTTP / 2.0 est finalisé. (Vous le connaissez dans son projet de SPDY.)


20
2017-10-27 16:38



Vous pouvez essayer ceci: curl -0 -v 'http://www.google.com/foo', curl -v 'http://www.google.com/foo', ils répondent la version 1.0 ou 1.1 de 404 correctement mais pas dans mon cas. - Ryan
Google exploite un serveur Web personnalisé et fait tout ce qu'il veut. Et alors? - Michael Hampton♦
Non, nginx ne rétrogradera jamais la version de la réponse vers la version 1.0. D'autre part, il n'utilisera pas de fonctionnalités de protocole non disponibles dans HTTP / 1.0. Par exemple. il n'essaiera pas de maintenir la connexion en vie et n'utilisera pas de codage de transfert en bloc. - Maxim Dounin
@MimimDounin, voulez-vous dire que lorsque nginx sait que le client ne prend pas en charge la version 1.1, il enverra quand même la réponse en tant que version 1.1, mais sans la fonctionnalité 1.1 actuelle? Ne serait-ce pas déroutant? - Ryan
Il est en ligne avec RFC 2145 et permet aux clients de connaître la version HTTP prise en charge par un serveur sans demandes supplémentaires. Vous voudrez peut-être relire la RFC 2145 si vous trouvez toujours cela déroutant. - Maxim Dounin


Q. Quels sont les avantages de répondre à HTTP 1.1 lorsqu'une demande client pour HTTP 1.0?

En fait, il vous envoie une réponse compatible HTTP / 1.0. Il n'utilisera aucune fonctionnalité telle que keepalive nécessitant HTTP / 1.1.

La raison en est que c'est un moyen peu coûteux pour le serveur de dire:

"hé, je sais que vous m'avez envoyé une requête en utilisant HTTP / 1.0, mais juste pour vous laisser   sais je UN M capable de HTTP /1.1. et voici la réponse à votre   demande initiale: [..]"

(Remarque: si le serveur supportait un HTTP / 1.8 fictif, il répondrait par cela.)

Cela vous évite une requête supplémentaire dans certaines situations. Si vous devez obtenir 3 URI différents à partir d'un serveur, vous pouvez envoyer le premier sous forme de HTTP / 1.0, puis passer à la version la plus récente prise en charge par le serveur et par les demandes ultérieures.


5
2017-11-15 11:08