Microsoft présente le premier prototype du serveur HTTP 2.0

Tout foutre à la poubelle et repartir de la page blanche ? C'est peut-être nécessaire, mais ça témoigne d'un problème de communication et de méthode. Si ces problèmes ne sont pas résolus, leur HTTP 3.0 suivra le même chemin. Les éditeurs préparent chacun leurs petits plats chez eux puis se réunissent autour d'une table et veulent faire tout avaler aux autres. Pas étonnant que ça finisse en indigestion, surtout avec un plat aussi lourd à digérer que SPDY.

Je pense que ça aiderait si toutes les spécifications du Web suivaient un modèle incrémental et non versionné. On est en train d'arrêter de versionner les specs HTML/CSS/JS : HTML5 est devenu HTML, les navigateurs implémentent déjà des bouts d'ES6 et d'ES7 sans qu'ES5 soit complètement supporté... On pourrait faire de même avec HTTP, de la détection de fonctionnalité plutôt que des normes versionnées. Cela permettrait une progression plus rapide et moins abrupte, tout en donnant davantage de pouvoir aux éditeurs pour choisir et faire évoluer les fonctionnalités qui leur sont chères. Pour reprendre ma métaphore, on sert les hors d'oeuvre, on voit ce qui part le plus vite et ce qui reste dans les assiettes, et on en déduit le menu à servir la prochaine fois.

Si c'est utilisé alors que la norme n'est pas finie, c'est qu'il y a un problème : une fois que quelque chose commence à être utilisé, ça n'est plus normalisable, et donc tu peux mettre ta norme à la poubelle, car tu ne pourras plus rien changer face à un géant du logiciel qui te dira "nous on fait comme ça, et si t'es pas content, c'est pareil".

Peut-être que la normalisation n'est pas adaptée au web dans ce cas. Mais je reviens a ce que je disais au dessus : normer quelque chose d'utilisé, c'est absolument inutile.

Ce n'est pas un très beau tableau du W3C que tu donnes là gangsoleil. Le W3C a un mode de fonctionnement très strict, certains de leurs documents de spécifications sont encore au stade de Candidate Recommendation alors que cela fait des années qu'on les utilise sur des sites grands publics. Ce sont les éditeurs qui veulent accélérer le mouvement, c'est d'ailleurs pour ça que la WHATWG a été créé et c'est pour ça qu'ils se prennent le chou régulièrement. Je dirais que le W3C est encore un des rares acteurs du web qui ait gardé un pied dans cette méthodologie télécom. Et ça ne leur donne pas forcément une bonne image auprès de la communauté de développeurs web qui ont tendance à foncer tête baissée sur les nouveautés dès lors qu'elles sont implémentées sur les trois navigateurs majoritaires. Je me rappelle encore quand ils ont viré le WebSQL, moi qui avait un service en prod qui fonctionnait avec...

Alors certes, c'est un gage de maturité et de fiabilité, mais c'est loin d'être l'idéal pour le business et l'innovation. La spécification HTML5 n'est toujours pas finalisée, et pourtant on en parlait déjà fin 2007 ! Qu'est-ce que ça aurait été si personne n'avait fait de site en HTML5 tant que le W3C n'avait pas mis son tampon "Recommendation" ? Quand je vois comment a évolué le Web ces 7 dernières années, je suis plutôt content que le Web suive cette méthodologie pour l'évolution des normes. Quitte à ce qu'il y ait quelques incidents de parcours, au moins on avance et à grande vitesse.

La remarque du developpeur FreeBSD est juste stupide : passer directement à HTTP 3.0 parce qu'ils n'arrivent pas a se mettre d'accord sur SPDY sur HTTP 2.0 ? Et ça sera quoi la prochaine fois ? Il ne trouve pas le café a son gout et il voudra passer au HTTP 4.0 ?
SPDY existe déjà, a prouvé qu'il était utile et performant. L'intégrer dans HTTP 2.0 est difficile c'est certain, mais est ce qu'il faut pour autant abandonner et passer à autre chose ? Je ne pense pas.

Bon alors l'idée est intéressante, mais en pratique, selon mon expérience, SPDY c'est quand même un peu du vent.

Déjà tout serveur web qui se respecte a une fonction nommée keepalive qui permet de réutiliser la même socket pour plusieurs requêtes HTTP consécutives. (sans multiplexage)
Mais même avec un keepalive à off, les temps cumulés d'établissement des socket TCP sur une page, c'est quoi ? 50ms ?

A peu près rien devant le temps de calcul des serveurs et de transfert des data....
Remettre en cause un truc qui marche quand même divinement bien et surtout aisément compréhensible par n'importe qui pour au mieux gagner quelque chose comme 2% de perf, moi, ça me laisse très dubitatif...

De mon point de vue, ce qui est pénible, c'est surtout que les browsers ne font jamais que 2 connexions simultanées par serveur...
ça c'est vraiment un point limitant...
A une époque ça a eu un sens et qualque part ça peut toujours en avoir pour éviter de tabasser les serveurs des petits sites. Mais en ce qui me concerne, j'aimerai bien pouvoir dire aux browsers de mes clients "allez y les gars, faites donc 30 sockets simultanées, on gère..."

Magnifique résultat de notre serveur x1.82 !!!!
http://http2.httptwo.com/analysis/st...84fc9e12dc2703