Je ne comprends pas ta réponse : WebSocket, c'est juste une surcouche à TCP dont le handshake se présente comme une demande d'Upgrade HTTP (pour que le serveur puisse être commun à un serveur HTTP justement, en tournant sur le même port) et une convention de formattage des frames pour distinguer données textes et binaires.
Dans les deux cas, une fois la communication établie, avec un handshake totalement trasparent du point de vue de Javascript (que ce soit un handshake TCP comme je le suggérais, ou WebSocket comme c'est le cas), tu te retrouves avec quelque chose de très bas niveau, qui n'a plus rien à voir avec du HTTP, sur lequel tu fais passer n'importe quoi comme données. Donc la couche Javascript est présente dans les deux cas (c'est le code exécuté côté client), et il n'y a pas de couche HTTP à gérer explicitement en plus dans mon idée.
Par contre, je viens de lire le draft WebSocket, du coup, et les considérations sur la sécurité développées par un autre commentateur me semblent une très bonne raison.
[^] # Re: websocket
Posté par MrLapinot (site web personnel) . En réponse à la dépêche Nouvelles des logiciels de navigation web. Évalué à 3.
Dans les deux cas, une fois la communication établie, avec un handshake totalement trasparent du point de vue de Javascript (que ce soit un handshake TCP comme je le suggérais, ou WebSocket comme c'est le cas), tu te retrouves avec quelque chose de très bas niveau, qui n'a plus rien à voir avec du HTTP, sur lequel tu fais passer n'importe quoi comme données. Donc la couche Javascript est présente dans les deux cas (c'est le code exécuté côté client), et il n'y a pas de couche HTTP à gérer explicitement en plus dans mon idée.
Par contre, je viens de lire le draft WebSocket, du coup, et les considérations sur la sécurité développées par un autre commentateur me semblent une très bonne raison.