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

  On 2010-09-16 15:17, Mikko Rantalainen wrote:
> 2010-09-13 16:44 EEST: Roger H?gensen:
>>   On 2010-09-13 15:03, Mikko Rantalainen wrote:
>>> And why do we need this? Because web servers are not behaving correctly
>>> and are sending incorrect Content-Type headers? What makes you believe
>>> that BINID will not be incorrectly used?
>> Because if they add a binary id then they obviously are aware of the
>> standard.
> And because Apache developers were obviously aware of the "Content-Type"
> header they implemented it correctly?... I
> also fail to see future where server software vendors provide perfect
> implementations.
We can dream can't we? *smiles*
>> Old servers/software would just pass the file through as they are
>> unaware so content type issues still exist there,
>> eventually old servers/software are rotate out until most are binary id
>> aware.
>> This is how rolling out new standards work.
>> A server would only add a binary id if none exist and it's certain (by
>> previous sniffing) that it's guess is correct,
> How about we add a new parameter to Content-Type header instead? For
> example, the server could send a file with a header such as
>
> 	Content-Type: text/plain; charset=iso-8859-1; accuracy=0.9
>
> and a "conforming" user agent should assume that there's 90% possibility
> that the given content type is correct. If accuracy is 1.0 ("100%") then
> sniffing MUST NOT be done. If the sniffing the UA is going has 95% hit
> rate the results from such sniffing should probably be used instead of
> HTTP provided content type if server provided accuracy is less than
> 0.95. I'll make it explicit that any sniffing done by UA should have a
> probability of error attached to the result. A sniffing result without
> probability for error has no value because otherwise a literal
> "text/plain" is a good heuristic for any file (see also: "Apache").
>
> This way server administrators could opt-out from any sniffing and an
> incompetent server administrator could specify global accuracy of 0.1 or
> something like that. Hopefully new web servers would then either provide
> no default accuracy at all or specify some low enough value that allow
> for sniffing.
>
> My point is that there's no need for BINID. My suggestion above is
> compatible with existing servers, content and UAs, as far as I know. In
> addition, it would provide a way to declare that the given content type
> should be trusted even if UA "thinks" that honoring the content type
> causes problems for viewing the content.

Now we're getting somewhere, I really like this proposal.
Actually, with your idea a binary id would complement this as a server 
supporting it could provide accuracy=1.0 in that case.

So I have to say that your accuracy parameter seems quick to add/support 
(both in http header, and in HTML5 meta and other appropriate places?)

And I doubt the Apache Foundation will have much issues supporting this 
either.

I guess we'll have to see what the rest thinks in this list but... a 
solution this slick..
it certainly has my vote, nice work Mikko *thumbs up*.

-- 
Roger "Rescator" H?gensen.
Freelancer - http://EmSai.net/

Received on Thursday, 16 September 2010 11:14:52 UTC