Pourquoi le navigateur ne peut-il pas envoyer de requête gzip?

Question

Si le serveur Web peut envoyer une réponse gzip, pourquoi le navigateur n'a-t-il pas demandé la requête gzip?

Answer 1

Le client et le serveur doivent se mettre d'accord sur la manière de communiquer. une partie de ceci est si la communication peut être compressée. HTTP a été conçu comme un modèle de requête / réponse, et la création originale a presque certainement été conçue pour toujours avoir de petites requêtes et des réponses potentiellement volumineuses. La compression n'est pas requise pour implémenter HTTP. Il existe des serveurs et des clients qui ne le prennent pas en charge.

La compression HTTP est implémentée par le client en indiquant qu'il peut prendre en charge la compression. Si le serveur le voit dans la demande et qu'il prend en charge la compression, il peut compresser la réponse. Pour compresser la demande, le client devrait avoir une "pré-requête". qui a en fait négocié que la demande serait compressée OU il faudrait exiger la compression en tant que codage pris en charge pour TOUTES les requêtes.

* UPDATE Feb '17 * Cela fait 8 ans, mais comme le note @ Phil_1984_, une troisième solution possible consisterait pour le client et le serveur à négocier le support de compression et à l'utiliser ensuite pour les demandes suivantes. En fait, des choses comme HSTS fonctionnent exactement de cette façon avec la mise en cache du client qui, selon le serveur, ne parle que TLS et ignore les liens non chiffrés. HTTP a été explicitement conçu pour être sans état, mais nous sommes allés au-delà de cela.

Answer 2

Un client ne peut pas savoir à l'avance qu'un serveur comprendrait une requête compressée, mais le serveur peut savoir qu'il en acceptera une.

Answer 3

Il le pourrait, à condition qu'il puisse garantir que le serveur l'acceptera. Cela peut signifier l’utilisation d’une requête OPTIONS.

Les navigateurs Web pourraient faire beaucoup de choses (par exemple, le traitement en pipeline) qu’ils ne font pas. Les développeurs de navigateurs Web étudient les conséquences d'un changement sur la compatibilité.

Dans un environnement hétérogène, il existe de nombreux serveurs et configurations Web différents. Modifier le mode de travail d’un client peut en briser certains.

Peut-être que 1% seulement des serveurs acceptent les demandes compressées, mais certains d'entre eux annoncent qu'ils le font, mais ne peuvent pas l'accepter correctement - de sorte que les utilisateurs n'auraient pas le droit de télécharger des fichiers sur ces sites.

Historiquement, de nombreuses implémentations client / serveur ont été mal exécutées. Pendant longtemps, les réponses au format compressé ont été brisées dans les principaux navigateurs Web (heureusement, ils sont presque tous disparus).

Vous obtiendriez donc des listes noires d'agents utilisateurs ou de serveurs (ou noms de domaine) où ces options étaient automatiquement désactivées, ce qui est désagréable.

Answer 4

Parce qu'il ne sait pas que le serveur peut l'accepter. Une transaction HTTP a une seule requête envoyée par le client, suivie d'une réponse. Le client envoie notamment l’encodage / la compression qu’il peut prendre en charge. Le serveur peut alors décider comment compresser la réponse. Le client n'a pas ce luxe.

Answer 5

Si vous écrivez une application Web, je suppose que vous contrôlez ce qui est envoyé au client et ce qui est renvoyé par le client.

Il serait assez facile d'écrire une implémentation de gzip en javascript, qui compresse les données de publication envoyées au serveur. Le serveur peut avoir un filtre (terme j2ee), sachant que les données du client sont envoyées compressées, ce filtre décompresse les données puis les transmet au servlet (ou aux classes d’action dans Struts) qui lisent les données normalement, par exemple. request.getParameter (...).

Cela semble parfaitement logique et faisable si vous êtes en contrôle. Comme d'autres publications le mentionnent, vous ne pouvez pas vous fier au navigateur pour le faire automatiquement, mais puisque vous écrivez les pages Web, vous pouvez le faire effectuer la compression que vous recherchez (avec un peu de travail).

Andy.

Answer 6

HTTP est conçu de cette façon:

• Le client dit sa demande en texte brut (y compris si peut comprendre les réponses compressées)
• Les réponses du serveur avec le codage propper (compressé ou non)

MAIS DANS CETTE CONCEPTION, le client ne peut pas envoyer de requêtes compressées car il ne sait pas si le serveur la comprendra à l'avance.