Re: comments on draft-barth-mime-sniffing

Joe D Williams wrote:
> There, I meant renderer to mean the player or whatever that friendly 
> thing behind the <audio> element is: the thingee that plays me.ogg and 
> knows literallyl nothing else about anything but .ogg and .wav.:)

OK.  So you don't mean the two different things one of which knows 
nothing about anything but .ogg and the other of which knows nothing 
about anything but .wav.  Gotcha.

So the "renderer" in your definition still needs to decide whether to 
handle the data as an OGG or a WAV.  With this definition, the UA does 
not indeed need to know anything about the kind of data it's handing the 
renderer.  The renderer does need to know what sort of data it's looking 
at, though.

> No, in my little fantasy of this case, there is only one renderer for 
> .ogg and .wav and that is all the host browser knows about for <audio>. 
> There is no choice, If I <audio my.ogg> all I care about is that the 
> host browser picks the 'built-in'  or native one that only knows about 
> these file types.

The "native renderer" as you call it then has to delegate to two 
completely different subsystems for the OGG and WAV cases.  How do you 
envision it picking which one to use?

> What can me.ogg do to corrupt the system using the simple native player. 
> ogg or .wav does not have and active form, I think.

You're assuming a completely non-buggy player.  That's desirable, but 
unlikely in practice.

> 'I see in the general sniffing algoritm that the file is read to look 
> for the internal contenttype in the header. If it finds this, then that 
> is the mime.
> 
> Yes, you can find the data structures in the detailed specs for the 
> streams but lookie here mr browser maker, I don't want to fool with all 
> that stuff.

No one is asking you to.

> I put me.ogg out there on my server somehow and then I have 
> an HTML 5 web page that says play what I put out there, please.

Sure.  And the browser will take that data, and treat it as what you 
tell it that data is.  If you lie to it... then it'll still treat it as 
what you tell it that data is.  Ideally, at least.

> The browser should let this happen with  no built-in security or other 
> delays except perhaps some user preferrence settings about multiple 
> media, on the level of a show images choice somdwhere.

I have no idea what you're trying to say here.

> Oh, I will look at that. If type is there, that should be clue enough to 
> start the player and start fetching the content

What's "the player"?  OGG and WAV need different "players".

> There should be no choice.

Choice by whom of what?

> Anyway, the correct thing to do is for the host browser not to worry 
> about it all. Just send the url to the player behind the <audio> or 
> <video> element and let it figure it out and when it is ready, let it 
> ask you for the content by url and really, just let the handler deal 
> witht the loading. I would hope the host has better things to do than 
> spoonfeed content to the audio or video handler.

What sort of media player are you using, exactly, that has a rich 
network stack built in?  In practice, it is exactly the browser's job to 
get the data and "spoonfeed" it to the player; the player just knows 
what to do with bytes, not with URLs.

> 'OK, let's make it like that in the spec. Right now are listing the 
> acceptable file types identified mainly by file extension.

Where, exactly?

> That is very enlightened and forward looking. However in this case where 
> all I want to do is play me.ogg I don't really care about all that. I 
> know what I put out there. Trust me.

Sure. We do! "You" in this case is the web server.  We'll handle the 
data based on what you tell us it is.

> Anyway, with these file extensions, what is the problem?

With which ones?

> If I can feed some string of bits from me.ogg after using an appropriate MIME in my 
> user code and and a retrievable file of me.ogg data from the server with 
> whatever contenttype and feed it directly to the hanler for <audio> 
> element and cause a problem then the problem is not mine, but the 
> browser makers who hasn't given me a safe place to play me.ogg.

Sure.  I'm still not sure what your point is...

> OK, I must step back a notch and focus just on <audio>.

OK...

> No problem for audio, right. Send the url or the file content as 
> instructed in the user code no sniffing needed because we trust the 
> author to have done the right thing.

Uh...  The sniffing is just needed to pick the right player, in the case 
when the author hasn't bothered to tell us what kind of media he's 
sending.  Assuming sniffing is done at all.

> I willhave to look at that in more detail. Are you saying there are .wev 
> files out there that this simple player is not going to play.

Sure.  Firefox, or example, is shipping a WAV player in version 3.5 that 
plays only a subset of the WAV files out there. 
https://bugzilla.mozilla.org/show_bug.cgi?id=475110 has some example WAV 
files attached that will not play in that player.

> However, in either of these, there is nothing that would give the player 
> the idea that there was some script it was supposed to execute or 
> anything wlse hazardous.

I'm not sure what script has to do with this whole thing....

> For me it is easy to draw the line: I'm just the simple little <audio> 
> player. I know I don't do much, but give me a chance. Host, get out of 
> the way and let me do it.
> For these file types, give me the bits straight for the server as fast 
> as you can and I will handle it.

OK. So you are a chunk of code that will take a byte stream and the MIME 
type and then do the right thing.  Fine.

> Great. But how is the server going to screw it up. I ask for the file 
> and he sends it, but uhoh he sends the wrong contenttype.

Well, define "wrong".  Not the one the author intended?  The browser 
can't read your mind; it can't tell whether the server is sending what 
you intended or not.  We can only assume that it is or isn't.  I'm 
arguing we should assume it is.  Others want to assume it isn't...

> Maybe not, maybe he is up to date or the webmaster has used .htaccess corretly. For 
> <audio> why do I care?

Because you need to decide whether to play it as a WAV or an OGG?

> Sorry, I don't. My htaccess is just fine, thank you. Somebody else may 
> be torched because the mime has not passed ietf or whoever and/or the 
> server has not been updated. Do I gotta take the wrap for that?

You're sort of responsible for what you put on the wire, yes.

> If it was, you wouldn't need to sniff for that. Sure, as we see, mostly 
> a user can manage to get .html served correctly as text/html or whatever 
> the recommendation.

Sure.  And CSS as text/css (and if he doesn't, a number of modern 
browsers won't treat it as CSS).  Why is this case different?

I can't tell what your point is, honestly....

> Maybe I will be luckler with <audio> and you won't try to oursmart me as 
> a author and user.

Right.  That's what I'm saying browsers should do: assume the 
author+server know what they're talking about and not try to 
second-guess them.

> But how do I fix my server?

That depends on the exact server you're using; I suggest contacting your 
hosting service (or server vendor if you configure your own server).

> I pick a file extension, like .x3d for instance, then I tell my server 
> (maybe via .htaccess) to serve that file extension as model/x3d+xml.

That's up to you.  Some servers use this model for configuration; others 
use other models.  Some servers support more than one approach to this 
problem (e.g. Apache).

> Why not fix that in the host browser by me telling it that if you see a 
> .x3d always treat it as being served as model/x3d+xml.

Because the host browser is not being run by you.  It's being run by the 
user...  Which means that you can't tell it anything directly.  All it 
knows is what the web server tells it.

> But really, from the server, as far as I know, it keys on file extension.

Some servers, sometimes, do that.  I can assure you that if you have a 
PHP script that serves an OGG file you do NOT want your server keying 
off the ".php" extension for the type.  Nor does it.

> Sure there are some fancy 
> extensionless negotiation concepts out there, but that is complex stuff 
> and this is easy.

And the point is that one shouldn't break people using the complex stuff.

>> I don't see why not.  We see it all the time now with objects, 
>> iframes, etc...
> 
> Some of those may be fallback content, or the <audio> may be fallback 
> content for object to get audio playing that wouldn't in an object that 
> asked for "house player"

What does fallback content have to do with anything here?

>> No, often enough they're just built from web pages that give the user 
>> a list of choices and ask him to pick one, then just have one script 
>> on the server that reads the data from somewhere (database, 
>> filesystem, whatever) and returns it.
> 
> Well, I think when you ask the sever for what to send, you will ask 
> something in a way that ends up with a file name and certain extension.

That's really the server's business...

> Then, once the server knows what file it is going to send, it looks up 
> the mime that is supposed to be in the head stuffs.

Again, that's the server's business.

> But even so, I don't think you are going to have success with that scale 
> of use for these simple elements. What you describe will work I guess, 
> but that sort of more side open stuff may work better with <object> and 
> a more full-featured player.

I have no idea what you're talking about here, honestly.

> Basically, please give me what I am asking for.

What are you asking for?

> A simple way to play <audio> and <video> from a very limited list of 
> input fomats.

You as an author?  We're giving you that.  You put the tag in your HTML, 
point it to your file, send the file with the right Content-Type.

What's the problem you're trying to solve here, exactly?

-Boris

Received on Friday, 19 June 2009 03:08:32 UTC