GZip plutôt que Deflate... et avec le rire
1 message
• Page 1 sur 1
Consultez la formation à Google Analytics de WebRankInfo / Ranking Metrics
-

hibou57 - WRInaute passionné

- Messages: 1154
- Inscription: 1 Nov 2006
GZip plutôt que Deflate... et avec le rire
Hi folks!
En me renseignant sur les différences entres GZip et Deflate, j’ai eu la surprise d’apprendre l’existence d’une autre succulante coquille dans le domaine des protocoles, faisant suite à l’une des plus célèbre faute d’orthographe au monde, celle de Referer au lieu de Referrer dans le RFC 2616. C’est encore cette RFC 2616 qui est en cause, mais cette fois, ce n’est pas ses auteurs qui ont mal lu le dictionnaire, mais ses utilisateurs qui ont mal lu la référence ! (quoique... il n’étaient pas aidés non-plus ; voir plus loin)
La RFC fait mention d’une méthode de compression et d’un format, qu’elle appel Deflate dans le texte tout en disant à juste titre qu’il s’agit du format zlib, pour lequel elle donne la référence RFC 1950, qui elle même s’appel “ZLIB Compressed Data Format ”, et non pas Deflate, qui est ce dernier, défini par la RFC 1951.
Vous suivez ?
Ben si tu suis, t’es fortiche, parce que justement, personne n’a suivi, et ce qui ne pouvait pas rater arrivât : ça a été la foire à l’emmêlage de pinceaux, et les implémenteurs de serveurs ou clients HTTP, qui n’ont pas bien lu la RFC 2616, ont simplement implémenté Deflate au lieu de ZLib.
Après ça, vous pourrez toujours répondre à des développeurs qui vous disent «vas donc lire la doc !», «le faites-vous vous-même ? »
Quoique… finalement est-ce peut-être tout simplement les auteurs de cette RFC 2616 qui était finalement de piètres rédacteurs (une célèbre coquille et une formulation ambigüe, qui ont toutes deux eu des conséquences irréversibles).
Bon, tout ça pour vous faire rire (si c’est raté, ben tant-pis), et pour dire que pour éviter les problèmes, il est préférable d’utiliser GZip plutôt que Deflat pour les réponses HTTP, et que si un serveur ou un CGI reçoit une requête avec Deflate, il n’a plus qu’à espérer que GZip figure dans la liste des formats acceptés, sinon il n’a plus qu’à tirer au hasard.
C’est dommage tout de même, parce que les Checksum présents dans GZip, le rende moins performant que Deflate/Zlib : Compression and performance - GZip vs. Deflate.
D’ailleurs, il est possible d’apprendre, dans les commentaires de la page Deflate compression browser compatibility and advantages over GZIP, que certains clients HTTP, ne supporte tout simplement ni ZLib ni Deflate. Peut-être à cause du malentendu absoluement garanti à ce sujet ?
Yellah, bonne nuit
En me renseignant sur les différences entres GZip et Deflate, j’ai eu la surprise d’apprendre l’existence d’une autre succulante coquille dans le domaine des protocoles, faisant suite à l’une des plus célèbre faute d’orthographe au monde, celle de Referer au lieu de Referrer dans le RFC 2616. C’est encore cette RFC 2616 qui est en cause, mais cette fois, ce n’est pas ses auteurs qui ont mal lu le dictionnaire, mais ses utilisateurs qui ont mal lu la référence ! (quoique... il n’étaient pas aidés non-plus ; voir plus loin)
La RFC fait mention d’une méthode de compression et d’un format, qu’elle appel Deflate dans le texte tout en disant à juste titre qu’il s’agit du format zlib, pour lequel elle donne la référence RFC 1950, qui elle même s’appel “ZLIB Compressed Data Format ”, et non pas Deflate, qui est ce dernier, défini par la RFC 1951.
Vous suivez ?
Ben si tu suis, t’es fortiche, parce que justement, personne n’a suivi, et ce qui ne pouvait pas rater arrivât : ça a été la foire à l’emmêlage de pinceaux, et les implémenteurs de serveurs ou clients HTTP, qui n’ont pas bien lu la RFC 2616, ont simplement implémenté Deflate au lieu de ZLib.
Après ça, vous pourrez toujours répondre à des développeurs qui vous disent «vas donc lire la doc !», «le faites-vous vous-même ? »
Quoique… finalement est-ce peut-être tout simplement les auteurs de cette RFC 2616 qui était finalement de piètres rédacteurs (une célèbre coquille et une formulation ambigüe, qui ont toutes deux eu des conséquences irréversibles).
Bon, tout ça pour vous faire rire (si c’est raté, ben tant-pis), et pour dire que pour éviter les problèmes, il est préférable d’utiliser GZip plutôt que Deflat pour les réponses HTTP, et que si un serveur ou un CGI reçoit une requête avec Deflate, il n’a plus qu’à espérer que GZip figure dans la liste des formats acceptés, sinon il n’a plus qu’à tirer au hasard.
C’est dommage tout de même, parce que les Checksum présents dans GZip, le rende moins performant que Deflate/Zlib : Compression and performance - GZip vs. Deflate.
D’ailleurs, il est possible d’apprendre, dans les commentaires de la page Deflate compression browser compatibility and advantages over GZIP, que certains clients HTTP, ne supporte tout simplement ni ZLib ni Deflate. Peut-être à cause du malentendu absoluement garanti à ce sujet ?
Yellah, bonne nuit
1 message
• Page 1 sur 1
Formation recommandée sur ce thème :
Formation Google Analytics : en 2 jours, apprenez comment exploiter l'essentiel des possibilités de l'outil de mesure d'audience de Google. Formation animée par les experts Google Analytics de Ranking Metrics.
Tous les détails sur le site Ranking Metrics : programme, prix, dates et lieux, inscription en ligne.
Lectures recommandées sur ce thème :
- Compression d'un .js par DEFLATE
- Comment ajouter dans chaque vhost ceci SetOutputFilter DEFLATE
- gzip et 1&1
- Compression Gzip
- [script] gzip : js et css
- Compression Gzip/css
- Compression .js et .css avec gzip
- compression gzip config Apache ?
- Demande d'aide Sivit et Gzip
- Compression gzip : Comment savoir ?
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité
