XmlHttpRequest bug?

Question

J'écris un programme qui, entre autres, doit télécharger un fichier avec son URL. Je suis trop paresseux pour implémenter les protocoles Http/Https manuellement, de sorte que j'ai besoin d'une bibliothèque/objet/fonction qui fera le travail.

Critique requise: le téléchargement doit être être asynchrone. Autrement dit, le thread qui a émis le téléchargement doit être capable de faire autre chose "pendant" le téléchargement du fichier, plus le téléchargement doit pouvoir être annulé à tout moment sans effets secondaires barbares (tels que l'appel interne au TerminateThread).

Nice-to-have exigences:

• devrait être en mesure de télécharger le fichier "en mémoire". Moyens - lire le contenu du fichier dès son arrivée, pas nécessairement l'enregistrer dans un fichier "système de fichiers".
• Ce serait bien d'avoir un mécanisme pratique de notification de progression Win32 (waitable event, semahpore, port de complétion, etc.), plutôt que d'interroger périodiquement l'état du téléchargement.

J'ai choisi l'objet COM XmlHttpRequest pour effectuer le travail. Il a semblé fonctionner assez bien, plus il a soutenu le mode asynchrone.

Cependant, j'ai remarqué qu'après un certain temps, il ne fonctionne plus. En d'autres termes, après plusieurs téléchargements de fichiers réussis, le téléchargement est interrompu.

Je l'interroge périodiquement pour obtenir son statut, il signale "en cours", mais rien ne se passe réellement, et il n'y a pas d'activité réseau. De plus, lorsque le même processus crée une autre instance de l'objet XmlHttpRequest pour effectuer de nouveaux téléchargements, l'effet est le même. L'objet signale "en cours", alors qu'il n'essaie même pas de se connecter au serveur (selon les sniffers du réseau et l'état TCP du système).

La seule façon de faire fonctionner cet objet est de redémarrer le processus. Cela me fait penser qu'il y a une sorte de bug (désolé, je voulais dire non documenté) dans l'objet. De plus, ce n'est pas un bug au niveau d'un objet individuel, puisque le problème persiste quand l'objet est détruit et qu'un autre est créé. C'est probablement un état global de la DLL qui implémente cet objet.

Est-ce que quelqu'un sait quelque chose à ce sujet? Est-ce un bug connu? Je suis sûr qu'il n'y a aucune chance que j'ai un autre bug dans mon code, à cause de ce qui me semble être le bug est dans le XmlHttpRequest. J'ai fait assez de tests et passé du temps avec le débogueur pour conclure sans doute raisonnable que c'est juste que l'objet cesse de fonctionner.

BTW, alors que l'objet devrait fonctionner, je fais toute l'attente via les appels API MsgWaitXXXX. Alors que si cet objet a besoin de la boucle de message pour fonctionner correctement (par exemple, il peut créer une fenêtre de notification cachée et la lier à un socket via WSAAsyncSelect) - Je lui donne l'occasion.

Answer 1

Je sais par expérience que l'implémentation Microsoft de XmlHttpRequest n'est pas entièrement conforme à la norme draft standard. En particulier, les mandats normalisés qui transmettent des données en continu devraient pouvoir être extraits à l'état prêt '3' (réception), IE deliberately ignores.

Malheureusement, je n'ai pas vu ce que vous décrivez malgré l'utilisation intensive d'objets XmlHttpRequest pour de longues interrogations.