Pourquoi le navigateur ne peut-il pas envoyer de requête gzip?
Si le serveur Web peut envoyer une réponse gzip, pourquoi le navigateur ne demande-t-il pas une requête gzip?
Le client et le serveur doivent s'entendre 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 était presque certainement envisagée de toujours avoir de petites requêtes et des réponses potentiellement volumineuses. La compression n'est pas nécessaire pour implémenter HTTP, il y a 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é-demande" qui négociait effectivement que la demande serait compressée OR, il faudrait exiger une compression en tant que codage pris en charge pour TOUTES les demandes.
* UPDATE Feb '17 * .__ Cela fait 8 ans, mais comme le note @ Phil_1984_, une troisième solution possible serait que le client et le serveur négocient le support de compression et l'utilisent ensuite pour les demandes suivantes. En fait, des choses comme HSTS fonctionnent exactement de cette manière 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 plus loin à ce stade.
Un client ne peut pas savoir à l'avance qu'un serveur comprendrait une demande compressée, mais le serveur peut savoir qu'il en acceptera une.
Il pourrait le faire, à condition qu'il puisse garantir que le serveur l'acceptera. Cela peut vouloir dire utiliser 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 examinent 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. Changer le mode de travail d'un client peut en briser certains.
Seulement 1% des serveurs acceptent peut-être des demandes compressées, mais certains d'entre eux annoncent ce qu'ils font, mais ne peuvent pas l'accepter correctement. Les utilisateurs ne seraient donc pas autorisés à télécharger des fichiers sur ces sites.
Dans le passé, de nombreuses implémentations client/serveur avaient été mises en œuvre de manière erronée. Pendant longtemps, les réponses gzippées étaient interrompues dans les principaux navigateurs Web (heureusement, elles sont presque toutes maintenant disparues).
Vous vous retrouveriez donc avec 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.
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.
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 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 souhaitée (avec un peu de travail).
Andy.
HTTP est conçu de cette manière:
- 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 le comprendra à l’avance.