And like I said before, please be careful of assuming our intent and desires from the way things currently work. We are thinking, listening, and implementing (and fixing bugs, and re-inspecting older behavior in lower-level code), so there is some...flexibility...I think.
On Sep 7, 2010, at 9:12 , Maciej Stachowiak wrote: > > On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote: > >> On Tue, 07 Sep 2010 11:51:55 +0200, And Clover <and...@doxdesk.com> wrote: >> >>> 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. >> >> IE9, Safari and Chrome ignore Content-Type in a <video> context and rely on >> sniffing. If you want Content-Type to be respected, convince the developers >> of those 3 browsers to change. If not, it's quite inevitable that Opera and >> Firefox will eventually have to follow. > > At least in the case of Safari, we initially added sniffing for the benefit > of video types likely to be played with the QuickTime plugin - mainly .mov > and various flavors of MPEG. It is common for these to be served with an > incorrect MIME type. And we did not want to impose a high transition cost on > content already being served via the QuickTime plugin. The QuickTime plugin > may be a slightly less relevant consideration now than when we first thought > about this, but at this point it is possible content has been migrated to > <video> while still carrying broken MIME types. > > Ogg and WebM are probably not yet poisoned by a mass of unlabeled data. It > might be possible to treat those types more strictly - i.e. only play Ogg or > WebM when labeled as such, and not ever sniff content with those MIME types > as anything else. > > In Safari's case this would have limited impact since a non-default codec > plugin would need to be installed to play either Ogg or WebM. I'm also not > sure it's sensible to have varying levels of strictness for different types. > But it's an option, if we want to go there. > > Regards, > Maciej > David Singer Multimedia and Software Standards, Apple Inc.
