Il faut aussi voir ce qu'on gagne en passant à du binaire.
Je crois que plus trivialement la question qui se pose est d'éviter la compression et d'être efficace dans l'implémentation. Tes en-tête binaires, tu les colles dans une structure (qui au passage existe déja dans toutes les implémentations ou presque (ici httpd.h de chez apache)) :
Oh ! surprise, on traduit en binaire des en-têtes texte pour pouvoir appliquer des masques comme par exemple dans nginx (modules/ngx_http_static_module.c) :
if(r->method&NGX_HTTP_POST){
Pour la surabondance et le foutoir, on peut toujours prier ou militer. Apparemment c'est mal barré (http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-19). Mais je crois qu'il ne faut surtout pas se tromper de débat. La question qui est posée est texte compressé vs binaire, pas texte rationnel vs binaire. On peut concevoir que ce ne soit pas le bon débat mais c'est ainsi qu'il se pose. C'est ce que j'ai essayé d'évoquer en filigrane dans l'article. HTTP/1.1 ayant la place qu'il a aujourd'hui, il va être remplacé par un protocole beaucoup plus agressif. C'est un fait. Cela signifie entre autre que le débat binaire / texte est déja tranché. Ce sera binaire, reste à savoir si ce sera du binaire intelligent que tu colles dans ta structure après t'être posé trois questions ou le charabia actuel comprimé qu'il faudra décomprimer avant de le parser pour finir par faire finalement une structure binaire (retour en 1) que tu va exploiter, puis refaire le chemin inverse.
Et il me semble qu'au niveau de l'efficacité d'une implémentation, il n'y a pas photo entre les deux propositions.
[^] # Re: Entêtes binaires???
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 9.
Je crois que plus trivialement la question qui se pose est d'éviter la compression et d'être efficace dans l'implémentation. Tes en-tête binaires, tu les colles dans une structure (qui au passage existe déja dans toutes les implémentations ou presque (ici httpd.h de chez apache)) :
Oh ! surprise, on traduit en binaire des en-têtes texte pour pouvoir appliquer des masques comme par exemple dans nginx (modules/ngx_http_static_module.c) :
Pour la surabondance et le foutoir, on peut toujours prier ou militer. Apparemment c'est mal barré (http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-19). Mais je crois qu'il ne faut surtout pas se tromper de débat. La question qui est posée est texte compressé vs binaire, pas texte rationnel vs binaire. On peut concevoir que ce ne soit pas le bon débat mais c'est ainsi qu'il se pose. C'est ce que j'ai essayé d'évoquer en filigrane dans l'article. HTTP/1.1 ayant la place qu'il a aujourd'hui, il va être remplacé par un protocole beaucoup plus agressif. C'est un fait. Cela signifie entre autre que le débat binaire / texte est déja tranché. Ce sera binaire, reste à savoir si ce sera du binaire intelligent que tu colles dans ta structure après t'être posé trois questions ou le charabia actuel comprimé qu'il faudra décomprimer avant de le parser pour finir par faire finalement une structure binaire (retour en 1) que tu va exploiter, puis refaire le chemin inverse.
Et il me semble qu'au niveau de l'efficacité d'une implémentation, il n'y a pas photo entre les deux propositions.