Re: comments on draft-barth-mime-sniffing

>> Sorry Adam, I am saying any UA sniffing except the file extension 
>> is fruitless in the cases of <audio> and <video> given the spec 
>> group of content types allowed for these elements. In particular, 
>> the served content type is unpredicable and there is nothing inside 
>> the file that UA needs to know about before passing this type of 
>> file to the handler.
>
> 1) I'm not quite clear on the distinction between "UA" and "handler" 
> that you're drawing here.  Can you clarify what you mean?  In 
> particular, if you claim that data-sniffing is not needed, then why 
> is extension-sniffing needed?

Hi Boris,
Given that I am looking at it from an author side, how about if the 
current browsing context or whatever higher order process does the 
top-level sniffing before it goes to the renderer is called the UA, 
which contains a nested browsing context.<video> or <audio> element. 
So in these cases I will call the browser the host UA and the <video> 
element the home of the handler which actually does the rendering.

I would like to say that data-sniffing is not needed. Can the target 
files contain any security problems?
I don't think you will find a MIME string in there unless specially 
authored into the file.
.
The author should include both the mime and the target url in the 
element. If the type and file extension do not match the content model 
for the element then fallback. If the type and file extension match, 
then either send the file or URL to the player and let it do what it 
needs to do. At this time it is (may not) not reliable to rely upon 
the served ContentType so this cannot be used to reject the file. 
Data-sniffing of file internal structures by the UA could take place, 
but I don't think this would give the "standard" handler any 
additional info. Literally, the handler should be able to handle any 
.wav or .ogg spec files. The handler may need to do some data-sniffing 
to get set up. but all it needs from the UA is the content.

Again, the load on the author should be no more than getting the type 
and file name correct for the element and it should just work.

>
> 2) Sniffing the file extension instead of the content significantly 
> complicates server-side solutions that, say, send different content 
> based on query params in the URL.  Of course these should arguably 
> send a Content-Type header anyway.

The file is there with the right extension but maybe I can't get 
control of the server and its defaults are not sufficient for the UA 
sniffer (like maybe I can't use htaccess). Is my document success 
going to depend on the fact that the server must be configured to send 
the specified MIME? If it is served wrong or even absent a MIME am I 
going to be saved by the UA data-sniffing to figure out that the 
misserved file is really OK?

> say, send different content based on query params in the URL.

Are we going to see this with these elements? We have already 
negotiated the content model down to a simple set. Many times those 
query forms are built from scripts that have determined or are 
determining some client capabilites? The application and content types 
of these elements seems quite clear as defined by the kestrokes that 
actually appear in the element code at run time. .

> -Boris

Thank You and Best Regards,
Joe

Received on Wednesday, 17 June 2009 20:09:53 UTC