What’s the FIRST thing you’re going to want to add after you figure out how to programatically request web pages through Microsoft’s WinINet HTTP API? Perhaps add a timeout? Forget it.
UPDATE: Even with my snotty tone, I still got some great feedback from someone at Microsoft, Ari Pernick, about the state of things – see the comments. Thanks Ari!
From MSDN:
SYMPTOMS
Calling InternetSetOption (or MFC CHttpFile::SetOption) with INTERNET_OPTION_SEND_TIMEOUT or INTERNET_OPTION_CONNECT_TIMEOUT does not set the specified timeout values.RESOLUTION
To work around the problem you can use asynchronous WinInet mode, which prevents the WinInet function call from blocking while waiting for a connection. Please see the Internet Client SDK documentation for more information about using WinInet asynchronously.
As if it weren’t hard enough to set up the synchronous HTTP connection… I already did the threading for it, all I wanted was a timeout. And when they say “for more information”, don’t think they mean all of it. I’ve seen the word “nightmare” used to describe it more than once. There are attempts at this on CodeProject here and here, but nothing too straightforward. There is documentation in MSDN, and a sample, time to dig in…
Looks like there is a newer WinHTTP API, with an example on CodeProject. But no multipart form post, reduced cookie and cache handling, incompatible with anything pre-Windows XP (you can use Win2k with the 5.0 release, which Microsoft has purged from MSDN), etc… and still, it’s overly complex with shoddy docs… I love that word, “shoddy”, and I got to use it twice today!
While we’re at it, check out the kludgy way Microsoft has you deal with invalid SSL certificates (I guess they think that never happens when you use REAL “vendors”). Bonus: includes “goto” statements!!
I guess Microsoft has moved on, to working on the C# interfaces… I yearn for the beauty of perl’s WWW::Mechanize…
Wow, CodeProject gave me the results below. If CodeProject can’t get IIS to run properly, who can?
—
ASP Engine error
The ASP engine on this server (IIS 5) is prone to crashing under high load. No specific error has occurred – it’s simply that the server has collapsed and will be restarted within the minute by our health monitoring systems.
Please try again and you will hopefully be routed to a different, healthier server.
Actually.. we haven’t moved on quite yet.
IE7/Windows Vista contains a lot of fixes for WinInet but we avoided interfaces changes for this release. You can file bugs against specific things you don’t like in WinInet and WinHTTP at our connect site at http://connect.microsoft.com. To get in you should choose “Available Programs” and then “Windows Networking Developer Platform” and hit Apply . Once you are in there is “Submit Feedback†button. Sorry for the passport + registration, that should get fixed in a week or two.
We created a WinInet Async sample that should be in the next SDK, but I’ve gone ahead and posted it up on the connect site’s downloads section.
Also we are working on a replacement for WinInet / WinHttp. There is a survey to help us with the planning for it on the connect site mentioned above. Please if you have a few minutes go and fill it out.
Finally there is a blog we keep for this stuff at http://blogs.msdn.com/wndp, the WinInet category is http://blogs.msdn.com/wndp/archive/category/10407.aspx and the WinHttp category is http://blogs.msdn.com/wndp/archive/category/10408.aspx
Ari, thanks for the feedback. I usually get a little hot when I find things more difficult than I expect, sorry. Thanks for all the good info. And a new sample, awesome! Time to dig in. :>
Ari, I took the survey. I don’t see the WinInet Async sample up on the connect web site – the only sample there right now is [WinSock LSP]. The blogs don’t seem to mention it either. Any more information?
I would love to get synchronous WinInet working with a timeout, as easily as possible. But I guess any new sample code isn’t going to work for me on anything other than Vista? Or once I compile, will it run in older environments? And… I’m still fuzzy on whether I should use WinInet or WinHTTP… so many questions…
I responded at http://blogs.msdn.com/wndp/archive/2006/03/23/559468.aspx#591024 but I’ll also respond here. A last minute code review found some stuff we want to fix before we give the sample out. The code should work fine on shipping versions of WinInet, but I’ll make sure that we are testing it downlevel.
Regarding WinInet vrs WinHttp: The confusion between these two is some of the reason we are writing a new stack. I’m going add a “which should I use guide?†to the list of blog postings to be written. My advice is by default go with WinHttp, sync timeouts work there. However there is a lot of WinInet features that aren’t in WinHttp that makes the choice hard. On a more positive note, we have fixed sync timeouts on the new WinInet that comes with Windows Vista and also shows up with IE7.
Thanks Ari! I have to say I am grateful for all the informative and timely feedback, good stuff. I’ll try out the new sample when it’s ready (either on Connect https://connect.microsoft.com/downloads or in the next SDK). In the meantime, I’ll give WinHTTP sync a try.