HTTP reste un protocole texte sur une socket qui reçois des entêtes (une requêtes) et répond avec des entêtes + un corps.
On peut mettre ce que l'on veut dans les entêtes non ? Exemple dernièrement de la nouvelle entête pour permettre au xmlhttprequest d'aller taper à la porte d'un serveur distant.
Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ? C'est bien ce qui se passe pour le Content-Machin: gzip non ?
Si le client n'accepte pas speedy, il n'envoie pas la première entête. Si le serveur n'accepte pas speedy, il ne renvoie pas la réponse speedy puisqu'il ignore tout bêtement l'entente envoyée. On ne casse pas la compatibilité avec http, on peut avoir une transition en douceur et cela peut permettre :
1) entêtes réduites à partir de la deuxième requête (la première devant être compatible http standard)
2) plusieurs get dans la même requête à partir de la deuxième requête (ce qui consomme ce n'est pas la première requête, c'est les 400 autres pour l'xmlhttprequest ou les dizaines d'images
3) compression des entêtes à partir de la deuxième requête.
Ensuite, c'est quoi qui pose problème actuellement pour le push. Si on ouvre la socket et qu'elle reste ouverte, pourquoi le serveur ne peut pas envoyer de son plein gré des données ?
Si le problème c'est de demander au serveur d'ouvrir lui même la connexion, comme ces choses là vont passer les NAT et comment ces choses là vont s'assurer que l'ordinateur qui répond derrière est toujours le bon ?
Je n'ai sûrement rien compris au protocole, mais là comme cela je ne vois pas l'intérêt de casser le web (ou de créer un web 2.0 ;) pour ces points particuliers qui, j'ai l'impression, peuvent être règles avec http.
# Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
On peut mettre ce que l'on veut dans les entêtes non ? Exemple dernièrement de la nouvelle entête pour permettre au xmlhttprequest d'aller taper à la porte d'un serveur distant.
Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ? C'est bien ce qui se passe pour le Content-Machin: gzip non ?
Si le client n'accepte pas speedy, il n'envoie pas la première entête. Si le serveur n'accepte pas speedy, il ne renvoie pas la réponse speedy puisqu'il ignore tout bêtement l'entente envoyée. On ne casse pas la compatibilité avec http, on peut avoir une transition en douceur et cela peut permettre :
1) entêtes réduites à partir de la deuxième requête (la première devant être compatible http standard)
2) plusieurs get dans la même requête à partir de la deuxième requête (ce qui consomme ce n'est pas la première requête, c'est les 400 autres pour l'xmlhttprequest ou les dizaines d'images
3) compression des entêtes à partir de la deuxième requête.
Ensuite, c'est quoi qui pose problème actuellement pour le push. Si on ouvre la socket et qu'elle reste ouverte, pourquoi le serveur ne peut pas envoyer de son plein gré des données ?
Si le problème c'est de demander au serveur d'ouvrir lui même la connexion, comme ces choses là vont passer les NAT et comment ces choses là vont s'assurer que l'ordinateur qui répond derrière est toujours le bon ?
Je n'ai sûrement rien compris au protocole, mais là comme cela je ne vois pas l'intérêt de casser le web (ou de créer un web 2.0 ;) pour ces points particuliers qui, j'ai l'impression, peuvent être règles avec http.