- From: Joe D Williams <joedwil@earthlink.net>
- Date: Wed, 17 Jun 2009 13:09:10 -0700
- To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
- Cc: <ietf-http-wg@w3.org>, <public-html@w3.org>
>> 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