On 6/3/11 8:09 AM, Nils Dagsson Moskopp wrote:
Eduard Pascual<herenva...@gmail.com>  schrieb am Fri, 3 Jun 2011
10:23:25 +0200:

This grants the ability for any content provider to use an explicit
"Content-Disposition: inline" HTTP header to effectively block
"download links" from arbitrary sources.

… thus placing a burden on content providers. If browser makers think
content providers cannot even get their MIME types right (see image /
video sniffing discussion), what makes you think anyone would configure
headers for no immediate benefit?

There are two ways to get correct things to happen in a setup where the HTTP header is authoritative but optional and other sources can provide the information when the header is absent.

1)  Send the right header.
2)  Not send the header at all, and let other sources of information
    work.

In the content-type case, some popular web servers have historically defaulted to a third option: "Send a bogus header and to hell with it". As a result, almost no one uses option 2 above (since it involves at best reconfiguring the HTTP server and at worst switching to a different HTTP server), and doing option 1 is hard, so the situation ends up bad.

For content-disposition, on the other hand, the vast majority of content is already using option 2 above. That's the path of least resistance for content providers, so only providers who are trying to go out of their way to change the behavior will do something else. That significantly reduces the chances of them sending bogus headers.

-Boris

Reply via email to