屏幕小虫子
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.
我今天收到一封有趣的电子邮件，其中一位同事正在尝试确保所有浏览器都可以成功下载其公司的MSI安装程序。 他找到了一篇博客文章，我在Content-Disposition标头上写了《六年前》，并为Check Images带来了一些麻烦。 以防万一您不清楚，互联网上的6年就像一个世纪。
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标头是名称值对，因此可以轻松地将它们与ASP或ASP.NET中的Response对象一起添加。您可以这样使用它(HTTP标头)：
HTTP/1.1 200 OK <snip> Content-Disposition: filename=checkimage.jpg Content-Length: 76127 Content-Type: image/JPEG
HTTP / 1.1 200 OK <snip>内容处置：filename = checkimage.jpg内容长度：76127内容类型：image / JPEG
Or, 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/JPEG
HTTP / 1.1 200 OK <snip>内容处置：附件； filename = checkimage.jpg内容长度：76127内容类型：图片/ JPEG
However, Internet Explorer has never really got it right.
但是，Internet Explorer从未真正做到正确。
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. 在IE 6.0上，大多数情况下都可以运行，但是如果您还设置了Cache-Control：no-cache，则建议的文件名(和类型！)将被忽略。 如果您必须在安全性和便利性之间做出选择，那就太可惜了。 当然，安全必胜。
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
在IE 5.0上，建议的文件名可以更改您的文件名，请参阅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(包括6.0)上，有时浏览器都将使用地址栏中的文件名而不是Content-Disposition标头，并且使用IE5.5SP2，您应该更改UseCDFileName注册表项，请参阅Q303750 。 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?
IE并不是唯一一个在此标头周围遇到麻烦的浏览器，但它一直是历史上最糟糕的浏览器。 去年，当IE8建议(在beta周期内)对Content-Type HTTP标头添加“ authoritative = true”时，取得了长足的进步。 这将是服务器基本上坚持认为它提供的Content-Type是正确的一种方法。 看起来很合理，就像应该一直那样，是吗？
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.
这是一个示例，说明了我们如何(根据该OLD提案)如何强制HTML页面以纯文本格式交付和呈现。 Sam Ruby认为，除了嗅探之外，这也是一个好主意，而在HTML5规范中通常被认为是一个坏主意。
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.
不幸的是，此博客文章从未更新过。 EricL ( Fiddler的作者，非常友好的人)写了它，他会知道我不是亲自挑选他，因为这是所有博客(包括我的博客)中的巨大问题。 当旧帖子过时时，真的很难更新。 这是一个手动过程，我们作为博客作者所能做的就是尽力利用指向新信息的指针来更新我们的旧帖子。
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.
在过去的两个月中，我们收到了社区的重要反馈，即在Content-Type标头上使用新属性会给服务器操作员带来部署难题。 为此，我们已将此选项转换为完整的HTTP响应标头。 发送带有值nosniff的新X-Content-Type-Options响应标头将阻止Internet Explorer MIME嗅探已声明的内容类型的响应。
For example, given the following HTTP-response:
例如，给出以下HTTP响应：
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?
有什么想法吗？
翻译自: https://www.hanselman.com/blog/these-are-the-little-bugs-that-lead-to-madness
屏幕小虫子
扫一扫
3781
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
