« AQtime Case Study: FeedDemon | Main | Thanks, Microsoft »

Friday, June 09, 2006

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451863669e200d8342b5d3253ef

Listed below are links to weblogs that reference Microsoft, Please Fix this WinINet Bug!:

» How long should a bug go unfixed? from TechBlog
All software has bugs. Some of them are severe enough to cause problems for users, while others are minor and resulting problems almost never surface. Some fall somewhere in between. They create problems, but they may not rise to the... [Read More]

» I wish I was famous from Awasu
Then I could get serious bugs in Windows that have been languishing for years in Microsofts fault database reactivated by bitching about them in my blog. No jokes, it took a tad over 7½ hours for an apology to arrive from the Windows product... [Read More]

» Microsoft have changed, seriously from Andy's blog
I woke up this morning to find that Nick Bradbury had posted about a particularly nasty WinINet bug that causes the application to hang (or in this case, the update thread sat on 100% cpu). Ive worked with this API a bit myself, and it... [Read More]

» A WinINet Chunked-Encoding Story from Windows Network Development
A couple of months back, Nick Bradbury of Homesite and FeedDemon fame posted a blog entitled, "Microsoft,... [Read More]

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Nick, have you posted something along these lines to our friends over at the IE blog?

He he. I was wondering when someone else was going to be hit by this. My reaction was pretty much the same as yours:

http://www.awasu.com/weblog/?p=213

BTW, don't even think about trying to change the user's HTTP setting. We tried it for a while and (upon reflection, rightly so) got spanked for it. It apparently breaks Windows Update under certain circumstances and can interfere with intranet logins.

Taka, thanks for letting me know I'm not alone here :) In your blog you asked people to install a specific upgrade which fixes this problem - how exactly did you fix it?

>>> how exactly did you fix it?

I didn't. That upgrade turned off (in code) the "Always use HTTP 1.1 even if the program is saying to absolutely, positively, definitely, without fail, use HTTP 1.0" registry setting but a few people reported problems because of it. You can search our forums for more details (I'm not going to link to anything because some of it is somewhat less than complimentary :-)).

My research suggested that it would be safe to do this but I included a debug switch to disable it. In hindsight, I should've done it the other way around: leave the problem active and tell people how to fix it (manually) if it surfaced. It was partly a psychological issue since I came across it almost immediately after 2.1 had been released and I was frantic because I thought it was because of something I had done.

AFAIK, there's no way to fix this other than to ask people to manually turn off the HTTP 1.1 setting. Luckily, I've never seen it again.

The other option is to use something other than WinInet which is flakey at best. At work, we ended up using the rather excellent LibCurl to get around many issues with wininet.

Dan, overall I've been pleased with WinINet, and I've got an awful lot of code invested in it, so I'd hate to dump it at this point.

Yeah, I've been having those kinds of issues with the latest build of FD. It not only spikes to 100% - but 100% across all four of my processors (double core Intel with HyperThreading). Not to mention, the update all feature "once an hour" doesn't seem to be sticking, but that may be an unrelated bug report.

Nick, we're taking a look at this. WinINET has undergone major updates for IE7, so it's interesting that you're still hitting this.

Do you have any repro URLs which consistently reproduce this problem? In working on Fiddler (http://www.fiddlertool.com) I haven't encountered any major sites which prematurely close chunked bodies, so it would be great to understand where you're hitting this problem.

Thanks!

Thanks for checking into this, Eric. Here are two feeds I see the problem with:

http://www.beingkatie.com/wp-rss2.php
http://meyerweb.com/eric/thoughts/rss2/full

Nick, I am so sorry this thing has caused you grief! For Vista, and going out with IE7 on XP/Win2K3, we have fixed a LOT of WinInet bugs, including a major cleanup of the cache.

As you noted, this particular bug can be difficult to reproduce, so I really appreciate the URLs. I reactivated the bug. Hope we can ask you for some help if we get stuck on it again.

If you're using WinInet or WinHTTP in your app, my team would be grateful if you could take some time to send us your input. Check out our blog for more on that.

You can also file bugs against WinInet (or any other of our components) via our connect site at http://connect.microsoft.com/wndp. Well-triaged bugs are always gratefully appreciated. For http client issues, it helps to make sure you can telnet on port 80 to the destination before shooting the WinInet messenger.

-David Powell
Product unit manager, Windows networking developer platform

Nick,

Long time ago I asked you if you were planning better support for Firefox, i.e., not to rely on Internet Explorer for displaying feed content. You said you were considering it, but it has never happened. Obviously, as pointed out here, the Internet Explorer is solution is not free of bugs; on the contrary, for years it has caused people a lot of grief without any solution to look forward to.

I hope you are still considering implementing Firefox as an alternative to IE.

Jeff

Jeff, an embedded Mozilla has been available for quite some time - see http://nick.typepad.com/blog/2004/05/hidden_feature_.html

Truth be told, though, the embedded Mozilla engine is far more buggy than IE, which is why it's an unsupported feature. I may be annoyed at MS for the WinINet bug, but regardless, they've done a far better job than Mozilla.org at making it easy to embed their browser.

David, thank you for posting here - I'm very pleased to hear that this bug has been reactivated. Please feel free to contact me about this (or any other) WinINet issue.

BTW, I've just subscribed to the WNDP feed and filled out the Web Client API planning survey.

You're welcome, Nick, and thanks for taking the time on the survey. We DL'd FeedDemon and were able to cause the hang. Will drop you a line when we know more.

Thanks for the URIs, Nick! Yup, these servers are definitely violating RFC2616 by failing to send the required "0" which terminates the chunked body.

(These pages are even sending "Keep-Alive" headers, which obviously isn't going to happen since they kill the connection.)

We'll look into our handling of this invalid behavior.

I can't say for sure, since I'm not an expert in server behavior, but my guess is that the RFC2616 violation is happening because meyerweb has, of late, been just terminating connections without warning. I'll get half a page to load, and then it just stops. If the same thing is happening with RSS feeds, then I'd guess that the termination is so abrupt no terminating 0 is emitted.

I think this might also be why Safari keeps giving me "lost network connection" error messages, though again, that's a guess. And not somethinig you Windows guys probably care much about anyway.

I would definitely do something different with handling, EricLaw, though I'll put in a plea to PLEASE keep things in the realm of generating an error, even a nice descriptve one that users could share with site owners. And not spiking the CPU.

Great to see MSFT taking this issue seriously. IE 7/Vista could be months away so a fix soon would be appreciated.

On the other hand FeedDemon has really blossomed lately. Well done Nick!

Nick, sounds like Mozilla.org is behind the curve on a stable embedded capability--how about Opera? I've grown to really like Opera, very fast and clean--seems like approaching Opera (even to suggest they provide this capability, if they don't already) would give customers more options.

...and thanks to both Nick and Microsoft for hopping on this so fast!

(I have also experienced the CPU spiking periodically, but it seemed to "get better" when I uninstalled Windows Defender Beta 1--WD Beta 2 seems okay as far as the CPU spiking goes. Don't know if there's any "real" relationship between WD and the CPU spiking, but I did find the Beta 1 problematic.)

I had no idea that Nick was this famous that Microsoft jumps in to fix the bug like that. So basically, Microsoft employees read your blog daily or was it the syndication that did it?

Nick, thanks for highlighting the meyerweb feed as a problem.

I removed it from my list of feeds, and now I can enjoy feeddemon without the cpu spikes.

I'm a happy guy again.

The meyerweb feed may have given some folks grief but it was helpful getting to the bottom of this thing. Definite bug in the parser code handling improperly formed chunked responses. Fix is pretty straight-forward and has FeedDemon running. Nick, can you please shoot me an email? We saw something else, while looking at this, which we wanted to run past you. Thx! -David

David, I'll follow-up by email.

Just to close the loop on this thing, we are pretty certain we've fixed the underlying bug. Our WinInet team got to the bottom of the bug before the sites Nick referenced made their changes. I doubt the fix made it into IE7 beta 3 on XP, but it should be in the final version when IE7 releases and should be in RC1 of Windows Vista (unless something unexpected happens).

Can I share some resources with you?

The comments to this entry are closed.