[whatwg] Video with MIME type application/octet-stream

On Tue, Sep 7, 2010 at 4:00 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 9/7/10 3:29 PM, Aryeh Gregor wrote:
>>
>> * Sniff only if Content-Type is typical of what popular browsers serve
>> for unrecognized filetypes. ?E.g., only for no Content-Type,
>> text/plain, or application/octet-stream, and only if the encoding is
>> either not present or is UTF-8 or ISO-8859-1. ?Or whatever web servers
>> do here.
>> * Sniff the same both for video tags and top-level browsing contexts,
>> so "open video in new tab" doesn't mysteriously fail on some setups.
>
> I could probably live with those, actually.

On Wed, Sep 8, 2010 at 5:33 AM, Philip J?genstedt <philipj at opera.com> wrote:
> I agree with Boris, the first two points are OK but the third I'd rather not
> implement, it's too much work for something that ought to happen very, very
> rarely.

That sounds promising.  What do other implementers think?

>> * If a file in a top-level browsing context is sniffed as video but
>> then some kind of error is returned before the video plays the first
>> frame, fall back to allowing the user to download it, or whatever the
>> usual action would be if no sniffing had occurred.
>
> This might be pretty difficult to implement, since the video decoder might
> consume arbitrary amounts of data before saying that there was an error.

And the problem is that you don't want to keep the data handy in case
it fails?  Hopefully it makes no big difference, then.

On Wed, Sep 8, 2010 at 1:14 PM, David Singer <singer at apple.com> wrote:
> what about "don't sniff if the HTML gave you a mime type" (i.e. a source element with a type attribute), or at least "don't sniff for the purposes of determining CanPlay, dispatch, if the HTML source gave you a mime type"?

What advantage does this serve?

On Wed, Sep 8, 2010 at 3:13 PM, And Clover <and-py at doxdesk.com> wrote:
> Perhaps I *meant* to serve a non-video
> file with something that looks a fingerprint from a video format at the top.

Anything's possible, but it's vastly more likely that you just made a mistake.

> I suggest:
>
> 1. Resources with no Content-Type continue to be fair game.
>
> 2. By far the most prevalent "maybe wrong" Content-Type that is widely
> deployed is text/plain, due to inappropriate web server defaults (both IIS
> and Apache<2.3). Allow sniffing of text/plain resources, but provide an
> override for server operators to say "I mean it, this is really text/plain".
> ie. standardise X-Content-Type-Options or something like it.
>
> 3. Sniffing should otherwise not occur in any context.

This is basically the same as what I suggested in my last post, right?
 Except for the "allow opting out of sniffing", which would be great
but is orthogonal.

> It's already different in different browsers, even with the small number of
> filetypes we currently have.

Because it's not standardized.

> In any case, any sniffing solution will always be inconsistent as different
> browsers, OSes, installed codecs and options expose different media
> filetypes to the net.

I don't follow.  A standardized sniffing solution can be implemented
across the board.

> Never mind just browsers, or even browsers that simply pass the resource to
> their underlying media frameworks for sniffing: there are far more
> already-deployed media players with HTTP capability than there are browsers
> with video/audio support. There is no chance we will ever be able to
> standardise the implementation of sniffing amongst this wide range of
> agents!
>
> So there will always be non-compliant UAs. In the face of this, we might as
> well standardise the 'good' solution - minimal sniffing - and hope to drag a
> few modern browsers along with that, instead of mandating an unreliable
> sniffing approach that *still* isn't implemented universally.

I don't follow this logic.  If these media players want to work the
same as browsers, they'll implement the spec.  If they don't implement
the spec, it makes no difference what the spec says, so why even
consider them?

> Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as
> even well-known sniffing behaviour continues to do (see the current
> publicised difficulties with CSS-inclusion attacks). Lack of sniffing
> behaviour, however, has never caused a vulnerability. It fails safe.

The CSS-inclusion attacks that I'm aware of involve @import-ing an
HTML document and observing what syntax errors occur.  There is no
sniffing that occurs there.  What attacks were you thinking of?

Received on Wednesday, 8 September 2010 12:58:39 UTC