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

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? Unfortunately, that was not the
case. They even thought that "Content-Type" was important enough that no
response should be without it. Unfortunately, that did not work out. I
also fail to see future where server software vendors provide perfect
implementations.

The best we can do is to make such errors visible. I think a good UA
could fix such errors automatically but such fixes should not be applied
silently. On the contrary: a good UA should assume that any fix is only
a best effort and there's a good possibility that the resulting content
is not equal to the one the original author tried to provide. As a
result, a good UA should inform the user and possibly give a probability
for the correctness of the content.

> 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.

> Any sniffing would be as a fallback only if the UA suspects the content
> type is wrong (i.e. <video> of type text for example) or similar,
> and it would not hurt to have some standardized behavior in those cases
> that sniff for something simple like a short binary id rather than parse
> potentially several kilobytes of the stream (which was where this
> discussion took off originally).

Why do you think that such incorrectly transferred videos should be
working? I think we should just specify that such videos will never
work. That would be interoperable and an author of such video would then
have some incentive to fix the Content-Type if he wants to distribute
the content.

I know that this has issues with already existing content which may be
working with some UAs regardless of invalid content type. See the
"accuracy" parameter above for a possible solution.

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100916/abea66c3/attachment.pgp>

Received on Thursday, 16 September 2010 06:17:41 UTC