I’m writing a program that among other things needs to download a file given its URL. I’m too lazy to implement the Http/Https protocols manually, so that I needed some library/object/function that’ll do the job.
Critical requirement: The download must be asynchronous. That is, the thread that issued the download must be able to do something else “while” downloading the file, plus the download must be able to be aborted anytime without any barbaric side effects (such as internal call to TerminateThread).
Nice-to-have requirements:
- Should be able to download the file “into memory”. Means – read the contents of the file as they arrive, not necessarily save it into some “file system” file.
- It’d be nice to have some convenient Win32 progress notification mechanism (waitable event, semahpore, completion port, etc.), rather than just periodically polling the download status.
I’ve chosen the XmlHttpRequest COM object to do the work. It seemed to work fine enough, plus it supported asynchronous mode.
However I noticed that after some period it just stops working.
That is, after several successful file downloads it stops downloading anything.
I periodically poll it to get its status, it reports “in-progress”, but nothing actually happens, and there’s no network activity. Moreover, when the same process creates another instance of XmlHttpRequest object to perform new downloads – the effect is the same. The object reports “in progress”, whereas it doesn’t even try to connect to the server (according to network sniffers and system TCP state).
The only way to make this object work back is to restart the process. This makes me suspect that there’s a sort of a bug (sorry, I meant undocumented feature) in the object. Also it’s not a bug at the level of an individual object, since the problem persists when the object is destroyed and another one is created. It’s probably some global state of the DLL that implements this object.
Does anyone know something about this? Is this a known bug?
I’m pretty sure there’s no chance that I have another bug in my code, because of which it seems to me to be the bug is in the XmlHttpRequest. I’ve done enoughtests and spent time with the debugger to conclude without reasonable doubt that it’s just the object stops working.
BTW, while the object should work, I do all the waiting via MsgWaitXXXX API calls. So that if this object needs the message loop to work properly (for instance, it may create a hidden notification window and bind it to a socket via WSAAsyncSelect) – I give it the opportunity.
I know from my own experiences that the Microsoft implementation of the XmlHttpRequest falls short of full compliance with the draft standard. In particular the standard mandates that streamed data should be able to be extracted in ready state ‘3’ (Receiving) which IE deliberately ignores.
Unfortunately I have not seen what you are describing despite using XmlHttpRequest objects extensively for long polling purposes.