These are the little bugs that lead to madness
I received an interesting email today where a fellow was trying to make sure that all browsers could successfully download his company's MSI installer. He had found a blog post that I wrote SIX YEARS AGO on the Content-Disposition header and some trouble I'd had with Check Images. Just in case you're not clear, 6 years is like a century years on the internet.
Here's a little snippet from my incredibly old blog post:
HTTP Headers are name values pairs, so they are easily added with the Response object in ASP or ASP.NET You use it like this (the HTTP Headers):
HTTP/1.1 200 OK
<snip>
Content-Disposition: filename=checkimage.jpg
Content-Length: 76127
Content-Type: image/JPEGOr, if you want to immediately prompt the user with a File Download Box:
HTTP/1.1 200 OK
<snip>
Content-Disposition: attachment; filename=checkimage.jpg
Content-Length: 76127
Content-Type: image/JPEGHowever, Internet Explorer has never really got it right.
Here's a list of gotchas, starting with my own:
- On IE 6.0, things mostly work, but if you ALSO setup Cache-Control: no-cache, your suggested filename (and type!) will be IGNORED. A bummer if you have to choose between security and convienence. Of course, security wins.
- On IE 4, the attachment option is flaky, see Q182315
- On IE 5.5, the attachment option is REALLY flaky, see Q267991 and Q279667 and Q281119
- On IE 5.0, the filename suggested can mangle your filenames, see Q262042
- On nearly all versions of IE, including 6.0, sometimes the browser will use the filename in the address bar instead of the Content-Disposition Header, and with IE5.5SP2 you're expected to change the UseCDFileName registry key, see Q303750. This was fixed with IE6.0SP1.
IE's not the only browser with past trouble around this header, but it's been the worst historically. Last year, IE8 made a good move forward when it proposed (during the beta cycle) an "authoritative=true" addition to the Content-Type HTTP header. This would be a way for your server to basically insist that the Content-Type it offered was the correct one. Seems reasonable, like it should have always been that way, eh?
Here's an example on how we'd (under this OLD proposal) force an HTML page to be delivered and rendered as plaintext. Sam Ruby thought it was a good idea as well as sniffing, while inside the HTML5 spec, is generally considered a bad idea.
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
Unfortunately this blog post was never updated. EricL (author of Fiddler and very nice person) wrote it, and he'll know I'm not picking on him personally, as this is a huge problem on all blogs, mine included. It's really hard to update old posts when they are obsolete. It's a manual process and all we as bloggers can do is our best to update our old posts with pointers to new information.
Two months later, this post came out and the final design that was agreed on with community feedback looked like this:
Over the past two months, we’ve received significant community feedback that using a new attribute on the Content-Type header would create a deployment headache for server operators. To that end, we have converted this option into a full-fledged HTTP response header. Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
For example, given the following HTTP-response:
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
I'd like this post to serve as a reminder to all of us who are blogging technical content to update our posts if and when appropriate, and certainly when a reader points out errata. As the gent who emailed me so wisely put it:
"These are the little bugs that lead to madness."
Thoughts?
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Chad Myers
But... I agree. Those little bug can drive any man to madness.
if we'd go back to all our old articles to update them whenever something about the subject changes, we're in a world of pain.
I'm all for republishing things with updated information, but going back to fix some syntax error just in case someone stumbles upon that one post? No thanks, I'm not Wikipedia and never claimed to know things in advance.
When as a seeking person I find something on the net, I can check the publish date and therefore make an educated guess about how relevant this information might be for today. If I try this out and it works, cool. if not, I'm back to searching for a better solution or figuring it out myself.
Usually a good post will help me anyway, if it's 99% right or 100%. What counts is that I get the idea how to fix it and maybe be able to spot the outdated mistake and fix it myself.
greetings Daniel
It's a poor user experience, and inconsistent behavior from browser to browser. And in the end, you always anyway have the "if download doesn't automatically start click here" link. The funny thing is that it's often quicker to click that link than wait for the automatic download to prompt you.
Add a "Last Checked for Accuracy" date so if I am keeping them updated people will know it.
Also, I might make a bot that sends me an email (or rss feed) on each annivarsary of a post and I can decide if I want to update it. I would at the least update the "Last checked for accuracy" date.
Looking at your post history you would have about 6 posts to verify each day. Once you point a post to a more recent one or intentionally marked a post as no longer relevent then it would not need reviewing anymore. That would keep it from being an ever growing problem.
Comments are closed.