Est-ce que http/1.0 est capable de gérer le contenu dégonflé et gzip? J'ai fini d'implémenter deflate et gzip dans mon serveur web minimaliste et je ne sais pas vraiment si les navigateurs avec http/1.0 sont capables de gérer le contenu compressé de gtap et de deflate.http/1.0 et deflate/gzip
Eh bien, c'est vraiment le navigateur; pas le protocole (HTTP 1.0 ne permet pas la compression assez heureusement)
Vous devriez examiner l'en-tête Accept-Encoding, qui sera soit gzip, deflate. Si l'en-tête n'est pas là, ne pas compresser.
Découvrez this rather extensive list. (La réponse courte semble être: Oui, ils le font).
Il semble y avoir différentes interprétations de ce que signifie deflate. HTTP 1.1 spécifie le format RFC 1950 (zlib) mais IIS produit un flux Deflate brut à la place. Internet Explorer ne peut pas gérer un flux RFC 1950 - il interprète l'encodage de contenu deflate comme RFC 1951 - vous pouvez donc vouloir éviter complètement ce format.
Le .NET DeflateStreamseulement implémente l'algorithme de compression Deflate, il ne crée pas le format Zlib.
Un problème avec la compression gzip et HTTP 1.0 est que dans de nombreuses circonstances, vous ne serez pas en mesure d'avoir des connexions keep-alive avec elle. Cela est dû au fait que vous ne pouvez pas utiliser l'encodage de transfert en bloc, donc cela s'applique quand gzip est fait à la volée. Il va juste rétrograder vers une connexion régulière non maintenue dans ce cas. De plus, si les fichiers sont pré-compressés et que le serveur peut afficher l'en-tête Content-Length au démarrage, cela ne pose aucun problème. – thomasrutter