- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 20 Jul 2010 13:07:21 +0300
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, public-html@w3.org
On Jul 19, 2010, at 20:42, Julian Reschke wrote: > On 19.07.2010 19:34, Boris Zbarsky wrote: >> ... >> Unfortunately, experience shows this to not be the case. A large >> fraction of "people" seem to upload their content to their web server, >> _maybe_ test it in the one browser they use, and move on. > > ... > > So there's a foreseeable race-to-the-bottom here. Please, this time, do not blame the server implementers. Well, I'd blame whoever's idea it was to use HTTP-level type labeling (specifically MIME) instead of relying on in-band magic numbers for Web content. In general, binary formats have magic numbers that are always at least an epsilon more reliable than MIME types, because there's always more server misconfiguration than there are accidental magic number collisions. (I'm well aware that HTML and XML don't have reliable magic numbers, but if MIME didn't exist, it would have been trivial to specify these formats to have mandatory magics--e.g. <?xml for XML which is not unfortunately optional.) While historical blame placement is useful for learning purposes, it doesn't necessarily help with solving problems already created. Thus, more pragmatically, I'd put the blame on Apache being easier to configure to send application/octet-stream as the fallback type than to configure to send no type as the fallback. (I don't know if it is even *possible* to make Apache omit the Content-Type header, but I do know how to make it send application/octet-stream.) Looking at how much of a FAQ it is[1] that <video> with Ogg doesn't work in Firefox when it works in Chrome, I think it would make sense to sniff even text/plain for magic number *in the <video> context*. [1] See Stack Overflow and #whatwg. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 20 July 2010 10:07:57 UTC