While reading up on how to properly respond to Accept-Encoding:gzip requests with a quick node server I'm hacking up, I ran into this support article about IE6:

In Internet Explorer, the Urlmon.dll file uses an internal buffer to read compressed data. Urlmon.dll fills this buffer when more data arrives and empties the buffer when Urlmon's client, Mshtml, reads data. The bytes that remain to be decoded in the buffer may be small (8 bytes or less) and the data contained in the buffer decompresses to 0 bytes. Frequently, this data is gzip frame data. When Mshtml receives 0 bytes, it thinks that all the data is read and closes the data stream. As a result, the HTML page sometimes appears truncated.

No, I'm not saying you necessarily need to code around the foibles of a now [thankfully] fairly rare version of IE.

What I am saying is that this is a rookie mistake that made it out of QA at one of the best software engineering companies (particularly in 2002-2003) there is, and in one of its marquee products. Anyone who has used streams has run into issues with buffers similar to this one. This is, at worst, a slight variation on theme.

Though I'm not suggesting you forgive bad code either, it is slightly comforting to know that, at least 12 years ago, Microsoft let something so [okay, potentially anachronistically] glaring slip.

Labels: , , , ,