2010-02-05 20 views
4

J'essaye de pousser des paquets de données de mon serveur HTTP vers un navigateur, en utilisant une Comet "forever iframe" et en alimentant les tags de script du serveur en utilisant le Transfer- Encodage: en-tête découpé. Ce que je trouve c'est que mes balises de script ne sont pas interprétées tout de suite, et je dois envoyer un certain nombre de morceaux avant que le navigateur commence à y répondre. Dans le cas de IE8 cela semble nécessiter quelque chose comme 256 octets de données (je n'ai pas vérifié avec précision), et dans Firefox 3.5.7, il semble être quelque chose de plus d'un kilo-octet. Je n'ai pas encore réussi à faire en sorte que Chrome réponde aux balises de script avant la fermeture de la connexion. Cependant, dans tous les cas, si je termine les données fragmentées (avec le bloc '0'), tous les morceaux tamponnés sont interprétés. J'ai trouvé quelques reference à ce genre de comportement sur Safari, mais je n'ai pas trouvé de telles informations pour d'autres navigateurs.Comment arrêter les communications Comet streamées dans le navigateur

Ce que je voudrais savoir, c'est comment puis-je exécuter de manière fiable ces balises de script lorsqu'elles sont envoyées, sans qu'il semble y avoir un mécanisme de mise en mémoire tampon retardant leur exécution?

Répondre

1

Avez-vous besoin d'utiliser pour toujours iframe? Si vous utilisez des websockets et retombez sur des sockets flash xml, vous pouvez prendre en charge tous les navigateurs actuellement en cours d'utilisation (sauf peut-être sur les téléphones à fonctions) et obtenir une véritable API de socket.

+0

Vous avez absolument raison ... et en fait c'est exactement ce que je fais maintenant. Au moment où j'ai posé la question, le support du HTML5 websocket n'était pas aussi mature qu'il l'est maintenant. Merci pour votre réponse, il arrondit bien cette question :) – NeilDurant