- From: And Clover <and-py@doxdesk.com>
- Date: Tue, 07 Sep 2010 11:51:55 +0200
On 09/07/2010 03:56 AM, Boris Zbarsky wrote: > P.S. Sniffing is harder that you seem to think. It really is... Quite. It surprises and saddens me that anyone wants to argue for *more* sniffing, and even enshrining it in a web standard. Sniffing is a perpetual disaster that, after several security-sensitive problems, web browsers have been moving to deprecate/mitigate. If browsers want to guess types when no Content-Type is specified(*) then fine, but there is no good reason to ignore an explicitly-set type. I don't want my `application/octet-stream` file download service to be repurposeable as a video player for some other party! For reasons already argued about here, you will never make the results of content-sniffing reliable, so why bother to standardise it? A standardised unreliable feature is no better than an unstandardised one. The typing mechanism of the web (and more) is Content-Type, period. There should be no confusion of this with officially-endorsed sniffing. That it is 'hard' for web authors to ensure the correct Content-Types are set is: * not W3/WHATWG's problem. If web servers make adding Content-Type information hard, then web servers need to be updated to make it easier; * not really true, at least for Apache which can allow AddType et al in the .htaccess files that low-end shared hosts use. This may not be widely-known or practised, but that doesn't really merit changing the standards for everyone else to cope with. (*: or, the traditional reason for sniffing, `text/plain`, due to Apache inappropriately sending this type for unknown files by default, bug 13986. That doesn't seem to apply here.) -- And Clover mailto:and at doxdesk.com http://www.doxdesk.com/
Received on Tuesday, 7 September 2010 02:51:55 UTC