Transfer-Encoding: gzip vs Content-Encoding: gzip

Question

Quel est l'état actuel des choses lorsqu'il s'agit de faire

Transfer-Encoding: gzip

ou un

Content-Encoding: gzip

quand je veux pour permettre aux clients avec par exemple une bande passante limitée à manifester leur volonté d'accepter une réponse compressée et le serveur ont la décision finale de savoir si ou de ne pas compresser.

Ce dernier est ce que par exemple Apache mod_deflate et IIS faire, si vous le laissez prendre soin de compression. En fonction de la taille du contenu d'être comprimé, elle ne le supplémentaires Transfer-Encoding: chunked.

Il comprend également un Vary: Accept-Encoding, qui a déjà fait allusion à ce problème. Content-Encoding semble être une partie de l'entité, de sorte que la modification de la Content-Encoding équivaut à un changement de l'entité, c'est à dire un autre Accept-Encoding - tête signifie par exemple un cache ne peut pas utiliser sa version en cache de la même entité.

Est-il une réponse définitive sur ce que j'ai manqué (et ce n'est pas enterrés à l'intérieur d'un message dans un long fil dans certains apache groupe de discussion)?

Mon impression est:

• Transfer-Encoding serait, en effet, être la bonne façon de faire ce qui est le plus souvent effectué avec Codage de Contenu par le serveur et le client implantations
• Content-Encoding, en raison de ses implications sémantiques, porte un couple de questions (ce qui devrait le serveur ne l' ETag quand il de manière transparente comprime une réponse?)
• La raison en est le poulet n'egg: les Navigateurs ne prennent pas en charge, parce que les serveurs ne sont pas, car les navigateurs ne pas

Donc je suis en supposant que le droit serait un Transfer-Encoding: gzip (ou, si j'en outre morceau du corps, il deviendrait Transfer-Encoding: gzip, chunked). Et aucune raison de toucher Vary ou ETag ou tout autre en-tête, dans ce cas, c'est un transport de la chose.

Pour l'instant je ne m'inquiète pas trop sur le "hop-by-hop" -ness de Transfer-Encoding, quelque chose que d'autres semblent s'inquiéter d'abord et avant tout, parce que les procurations peuvent décompresser et de l'avant non compressé pour le client. Cependant, les procurations pourraient tout aussi bien à l'avant comme ça (compressé), si la demande originale a le bon Accept-Encoding - tête, qui dans le cas de tous les navigateurs que je sais, c'est un fait.

Btw, cette question est au moins une dizaine d'années, voir par ex. https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Toute précision sur ce que ce sera apprécié. À la fois en termes de ce qui est considéré comme conforme aux normes, et ce qui est considéré comme pratique. Par exemple, client HTTP bibliothèques de l'appui transparent "Content-Encoding" serait un argument contre la praticité.

Answer 1

Citant Roy T. Fielding, l'un des auteurs du RFC 2616:

changement de codage de contenu à la volée de manière incohérente (ni "jamais" ou "toujours") rend impossible pour les demandes ultérieures quant à ce contenu (par exemple, METTRE conditionnelle ou GET) pour être traitées correctement. C'est, bien sûr, pourquoi l'exécution à la volée encodage de contenu est une idée stupide, et pourquoi j'ai ajouté Transfer-Encoding de HTTP comme la bonne façon de le faire à la volée, sans modification de l'encodage la ressource.

Source: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

En d'autres termes: ne pas faire à la volée de Contenu de Codage, utilisation d'Encodage de Transfert de place!

Edit: C'est, sauf si vous voulez servir le format de contenu pour les clients qui ne comprennent Encodage de Contenu. Qui est, probablement, la plupart d'entre eux. Mais sachez que vous laissez les domaines de la spécification et peut-être des questions telles que celle mentionnée par la mise en service ainsi que d'autres, par exemple lorsque les procurations sont impliqués.

Answer 2

La correcte utilisation, tel que défini dans la RFC 2616 et effectivement mis en oeuvre à l'état sauvage, est pour le client d'envoyer un Accept-Encoding - tête de demande (le client peut spécifier plusieurs encodages). Le serveur peut alors, et alors seulement, de coder la réponse au client le codage pris en charge (si le fichier de données n'est pas déjà stockées dans cet encodage), indiquer dans l' Content-Encoding - tête de réponse dont l'encodage est utilisé. Le client peut alors lire les données de la prise basé sur l' Transfer-Encoding (c'est à dire, chunked), puis de décodage sur la base de la Content-Encoding (ie: gzip).

Donc, dans votre cas, le client doit envoyer un Accept-Encoding: gzip - tête de la requête, puis le serveur peut décider de comprimer (si pas déjà fait) et d'envoyer un Content-Encoding: gzip et, facultativement, Transfer-Encoding: chunked - tête de réponse.

Et oui, l' Transfer-Encoding - tête peut être utilisé dans les requêtes, mais seulement pour de HTTP 1.1, qui exige que le client et le serveur implémentations de soutien à l' chunked d'encodage dans les deux directions.

ETag identifie de manière unique les données de la ressource sur le serveur, et non pas les données transmises. Si une URL donnée de ressources de l'évolution de ses ETag de la valeur, cela signifie que le côté serveur de données pour cette ressource a changé.