- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:57:39 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19036
Summary: Simplify <video> for implementors and authors by
ignoring the Content-Type HTTP header
Product: HTML WG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#loa
ding-the-media-resource
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: HTML5 spec
AssignedTo: dave.null@w3.org
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: ian@hixie.ch, mjs@apple.com, rubys@intertwingly.net,
mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org, julian.reschke@gmx.de,
simonp@opera.com, w3c@adambarth.com,
philipj@opera.com, adrianba@microsoft.com,
ayg@aryeh.name, singer@apple.com, cdouble@mozilla.com,
kennyluck@w3.org, yuhongbao_386@hotmail.com,
brunoaiss@gmail.com
This was was cloned from bug 11984 as part of operation LATER convergence.
Originally filed: 2011-02-05 00:08:00 +0000
================================================================================
#0 contributor@whatwg.org 2011-02-05 00:08:06 +0000
--------------------------------------------------------------------------------
Specification:
http://www.whatwg.org/specs/web-apps/current-work/complete/video.html
Section:
http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource
Comment:
Simplify <video> for implementors and authors by ignoring the Content-Type
HTTP header
Posted from: 85.227.154.141 by simonp@opera.com
================================================================================
#1 Simon Pieters 2011-02-05 00:18:13 +0000
--------------------------------------------------------------------------------
Rationale
The current state of implementations is a mess, as summarized by Ian Hickson
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/028291.html ):
"Microsoft's position is, as far as I can tell, that there's no point looking
at the Content-Type header, [...]"
"Safari does crazy things right now that we won't go into; [...]"
"Chrome right now sniffs like IE, [...]"
"Opera does what the spec suggests. [...]"
"Mozilla respects the Content-Type religiously, [...]"
The currently specified handling of Content-Type has concrete negative
side-effects for both implementors and authors, outlined in the following
sections.
Rather than continuing to maintain this mess, we should jump directly to the
most sane of the likely outcomes, which is to always ignore Content-Type for
<video>.
Issues for Implementors
* Because application/octet-stream is special-cased in canPlayType, the same
code path cannot be used for canPlayType as for checking Content-Type and
<source type>.
* In the resource fetch algorithm, if the resource is transferred using many
HTTP byte range requests, it's unclear if Content-Type should be checked on the
first request, or on every request. Either would be problematic:
- Checking it only once is inconsistent because on subsequent requests,
Content-Type may have changed, but this would be ignored.
- Checking it for every request could amount to very many times during the
playback of a long video. If the underlying media framework must be queried
each time, it could be time-consuming. Introducing caching to work around it
increases the risk of bugs.
* In order to be compatible with what is sent in Content-Type, implementations
must support several synonymous MIME types. This is exposed via canPlayType,
where there was no legacy to consider originally, creating unnecessary room for
incompatibilities. For example, Firefox supports 4 different MIME types for
WAVE, Opera supports 3 and Chrome supports 2.
(http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support )
Issues for Authors
* Because of the way application/octet-stream is special-cased, the result of
canPlayType is subtly different from how Content-Type and <source type> are
treated, which is confusing. For example,
canPlayType("application/octet-stream") returns "", while
canPlayType("application/octet-stream;") returns "maybe". Yet, using either
value in Content-Type should cause the user agent to use sniffing to determine
the resource type and try decoding it.
* Many servers are not configured to serve the correct Content-Type for audio
and video types:
- Authors who are not aware of the requirements on Content-Type will go
through time-consuming debugging before eventually learning how to configure
their server.
- Authors who cannot control what Content-Type HTTP header is sent by their
server will be unable to use <video> at all.
Details
* Remove all mention of application/octet-stream from the <video> section,
especially:
- The special-casing of application/octet-stream from the canPlayType
method.
* Remove all mention of Content-Type from the <video> section, especially:
- The following case from the resource fetch algorithm: "If the media
resource is found to have Content-Type metadata that, when parsed as a MIME
type (including any codecs described by the codecs parameter, if the parameter
is defined for that type), represents a type that the user agent knows it
cannot render (even if the actual media data is in a supported format)"
Impact
Positive Effects
* The behavior of <video> with respect to Content-Type is aligned with how e.g.
<img> already works.
* No more time is spent maintaining an unstable situation on which it is very
unlikely implementations will converge.
* Implementations of <video> are simplified.
* The incentive for supporting many different equivalent MIME types in
canPlayType and <source type> is removed, as they come only from legacy
Content-Type issues.
* Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from
implementations of canPlayType.
* Using <video> becomes simpler for authors.
Negative Effects
* Video will always play in a <video> context but may fail in a top-level
browsing content, depending on the Content-Type and what sniffing is used.
(This is already the situation for images.)
* Content-Type as the definitive mechanism for type information in HTTP is
undermined even further.
Conformance Classes Changes
User Agents
Risks
* Failure to standardize sniffing of video types may result in poor
interoperability. This is already the case, as the spec currently requires
sniffing after checking Content-Type. However, the risk does increases somewhat
when more implementations switch to always sniffing.
Note: Work on standardized sniffing for audio and video types has already begun
in Media Type Sniffing.
http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-01
(Note: This bug is basically foolip's CP for ISSUE-145
(http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType ). However,
I think his CP is not appropriate as a CP for ISSUE-145 since it makes a
substantive change while the original bug was about an editorial issue.
Therefore I think it is more appropriate for foolip's CP to be a separate bug,
hence this bug.)
================================================================================
#2 Ian 'Hixie' Hickson 2011-02-05 01:31:54 +0000
--------------------------------------------------------------------------------
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
http://dev.w3.org/html5/decision-policy/decision-policy.html
Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.
================================================================================
#3 contributor@whatwg.org 2011-02-05 01:32:11 +0000
--------------------------------------------------------------------------------
Checked in as WHATWG revision r5836.
Check-in comment: Bring the spec more in line with what the browsers do for
video (largely, ignoring Content-Type). This will probably be tweaked further
once Adam's draft has a section dedicated to sniffing media container formats.
http://html5.org/tools/web-apps-tracker?from=5835&to=5836
================================================================================
#4 Adam Barth 2011-02-05 02:09:54 +0000
--------------------------------------------------------------------------------
I've updated http://tools.ietf.org/html/draft-ietf-websec-mime-sniff to include
a hook for sniffing video specifically. Please let me know if you need other
hooks in that document.
================================================================================
#5 Julian Reschke 2011-02-05 10:43:27 +0000
--------------------------------------------------------------------------------
I believe this should be reverted, see
<http://lists.w3.org/Archives/Public/public-html/2011Feb/0114.html>.
================================================================================
#6 Adrian Bateman [MSFT] 2011-02-14 20:46:28 +0000
--------------------------------------------------------------------------------
Microsoft's position: IE9 RC strictly obeys the Content-Type returned to media
elements. We believe this behaviour matches the latest Firefox 4 Beta. Based on
feedback from developers and also following the "state of implementations"
thread highlighted by Simon above, we changed the implementation of media
elements between IE9 Beta and IE9 RC. While it required extra work in our
browser engine to respect the Content-Type in this way, it turned out that this
was less work than supporting a robust future-proof content-sniffing approach.
Consequently we disagree that this change simplifies things for implementers
and we request that the change be reverted.
Currently, we do not support media playback for content with the
application/octet-stream content type. The working group should consider
application/octet-stream support as a separate issue.
================================================================================
#7 Philip Jägenstedt 2011-02-14 21:45:27 +0000
--------------------------------------------------------------------------------
(In reply to comment #6)
> Microsoft's position: IE9 RC strictly obeys the Content-Type returned to media
> elements. We believe this behaviour matches the latest Firefox 4 Beta. Based on
> feedback from developers and also following the "state of implementations"
> thread highlighted by Simon above, we changed the implementation of media
> elements between IE9 Beta and IE9 RC. While it required extra work in our
> browser engine to respect the Content-Type in this way, it turned out that this
> was less work than supporting a robust future-proof content-sniffing approach.
> Consequently we disagree that this change simplifies things for implementers
> and we request that the change be reverted.
>
> Currently, we do not support media playback for content with the
> application/octet-stream content type. The working group should consider
> application/octet-stream support as a separate issue.
Uh, just when all browser vendors seemed to be OK with ditching Content-Type...
What about file:, ftp: and other protocols that don't have any equivalent of
Content-Type? What about when Content-Type is missing from a HTTP respsonse?
By reverting this change we'd be bringing back application/octet-stream which
you don't support. Wouldn't it be better to agree on something and change the
spec to that than to bring back something which doesn't match any browser and
never will?
================================================================================
#8 Chris Double 2011-02-14 23:26:44 +0000
--------------------------------------------------------------------------------
(In reply to comment #7)
>
> Uh, just when all browser vendors seemed to be OK with ditching Content-Type...
>
Firefox currently doesn't sniff and respects the Content-Type. We don't plan to
change this behavior at this stage. What I'd like to see is further work and
testing on the content sniffing algorithm before any decision is made to
change.
> What about file:, ftp: and other protocols that don't have any equivalent of
> Content-Type? What about when Content-Type is missing from a HTTP respsonse?
We have an internal mapping from file extension to content type for these
purposes.
> By reverting this change we'd be bringing back application/octet-stream which
> you don't support. Wouldn't it be better to agree on something and change the
> spec to that than to bring back something which doesn't match any browser and
> never will?
I'd also like the application/octet-stream issue to be dealt with separately as
per Microsoft's request.
================================================================================
#9 Sam Ruby 2011-02-15 00:16:52 +0000
--------------------------------------------------------------------------------
(In reply to comment #6)
> Currently, we do not support media playback for content with the
> application/octet-stream content type. The working group should consider
> application/octet-stream support as a separate issue.
Please file a separate bug report on this.
================================================================================
#10 David Singer 2011-02-15 03:25:54 +0000
--------------------------------------------------------------------------------
Content-type has decreasing utility; it fails to handle files that conform to
more than one standard (one file can simultaneously be valid as video/3gpp,
video/mp4, and video/3gpp2, for example). Many users cannot configure their web
servers to return correct content-types (it's not under their control). A a
declared attribute in the markup, type has utility. As a guess from the
file-extension by the web server, the utility is marginal at best; the UA can
and usually does do better at deducing what the correct type of a file is.
Given that you have to be prepared, at the UA, to disbelieve what you're told,
or adjust it, we question whether tangling the web server's guess into the UA
behavior makes life any simpler or more interoperable.
================================================================================
#11 Philip Jägenstedt 2011-02-15 08:47:02 +0000
--------------------------------------------------------------------------------
(In reply to comment #8)
> (In reply to comment #7)
> >
> > Uh, just when all browser vendors seemed to be OK with ditching Content-Type...
> >
>
> Firefox currently doesn't sniff and respects the Content-Type. We don't plan to
> change this behavior at this stage. What I'd like to see is further work and
> testing on the content sniffing algorithm before any decision is made to
> change.
I've discussed this with Robert O'Callahan, see
<http://krijnhoetmer.nl/irc-logs/whatwg/20110127#l-831>. I'm not surprised that
you're not a fan of the idea, though.
Should I take this that you'd consider dropping Content-Type if the solution
gets spec'd, tested and shipped in another browser?
> > What about file:, ftp: and other protocols that don't have any equivalent of
> > Content-Type? What about when Content-Type is missing from a HTTP respsonse?
>
> We have an internal mapping from file extension to content type for these
> purposes.
Even for missing HTTP Content-Type? How about Content-Type:
application/octet-stream?
> > By reverting this change we'd be bringing back application/octet-stream which
> > you don't support. Wouldn't it be better to agree on something and change the
> > spec to that than to bring back something which doesn't match any browser and
> > never will?
>
> I'd also like the application/octet-stream issue to be dealt with separately as
> per Microsoft's request.
Would that be ISSUE-145, or the issue of whether or not to play HTTP resources
with Content-Type: application/octet-stream ?
================================================================================
#12 Maciej Stachowiak 2011-02-17 11:17:27 +0000
--------------------------------------------------------------------------------
Since Microsoft and Mozilla do not implement the behavior resulting from this
bug, and seem unwilling to do so, it may be a good idea to revert the change
for now, pending further discussion. I say this even though Apple would
somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on
new information from Mozilla and Microsoft reps.
================================================================================
#13 Philip Jägenstedt 2011-02-17 11:57:07 +0000
--------------------------------------------------------------------------------
(In reply to comment #12)
> Since Microsoft and Mozilla do not implement the behavior resulting from this
> bug, and seem unwilling to do so, it may be a good idea to revert the change
> for now, pending further discussion. I say this even though Apple would
> somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on
> new information from Mozilla and Microsoft reps.
They also don't implement the behavior that would result from reverting this
bug, and seem unwilling to do so.
Unless we can all agree to implement some specific behavior, I'd prefer to
handle this as an ISSUE, to force everyone to make very specific suggestions
for what the spec should be.
================================================================================
#14 Julian Reschke 2011-02-17 12:06:16 +0000
--------------------------------------------------------------------------------
(In reply to comment #13)
> They also don't implement the behavior that would result from reverting this
> bug, and seem unwilling to do so.
Well, not all of it. Sam's advise was to have a separate bug for that.
> Unless we can all agree to implement some specific behavior, I'd prefer to
> handle this as an ISSUE, to force everyone to make very specific suggestions
> for what the spec should be.
Once the change in the spec is undone, you are of course free to escalate to an
issue.
================================================================================
#15 Sam Ruby 2011-02-17 14:16:20 +0000
--------------------------------------------------------------------------------
(In reply to comment #14)
> (In reply to comment #13)
> > They also don't implement the behavior that would result from reverting this
> > bug, and seem unwilling to do so.
>
> Well, not all of it. Sam's advise was to have a separate bug for that.
+1
> > Unless we can all agree to implement some specific behavior, I'd prefer to
> > handle this as an ISSUE, to force everyone to make very specific suggestions
> > for what the spec should be.
>
> Once the change in the spec is undone, you are of course free to escalate to an
> issue.
+1
================================================================================
#16 Philip Jägenstedt 2011-02-17 15:24:54 +0000
--------------------------------------------------------------------------------
Well, I'm hoping this will be closed as FIXED without reversion and that those
who disagree with that raise it as an ISSUE, but either way the end result
would be the same process.
================================================================================
#17 Julian Reschke 2011-02-17 17:00:57 +0000
--------------------------------------------------------------------------------
(In reply to comment #12)
> Since Microsoft and Mozilla do not implement the behavior resulting from this
> bug, and seem unwilling to do so, it may be a good idea to revert the change
> for now, pending further discussion. I say this even though Apple would
> somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on
> new information from Mozilla and Microsoft reps.
"may be a good idea" is kind of fuzzy. Can we please have an official statement
from the chairs? (asking because
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984#c16> indicates there's
still confusion)
================================================================================
#18 Philip Jägenstedt 2011-02-23 10:12:19 +0000
--------------------------------------------------------------------------------
(In reply to comment #17)
> (In reply to comment #12)
> > Since Microsoft and Mozilla do not implement the behavior resulting from this
> > bug, and seem unwilling to do so, it may be a good idea to revert the change
> > for now, pending further discussion. I say this even though Apple would
> > somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on
> > new information from Mozilla and Microsoft reps.
>
> "may be a good idea" is kind of fuzzy. Can we please have an official statement
> from the chairs? (asking because
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984#c16> indicates there's
> still confusion)
There is no confusion, just plain old disagreement. Normally when a bug report
is filed and the editor agrees and fixes it, it is those who disagree that
escalate the bug to an issue. I don't see why we should do anything differently
here, especially given that no one is willing to implement the previous state
either.
================================================================================
#19 Julian Reschke 2011-02-23 10:25:15 +0000
--------------------------------------------------------------------------------
(In reply to comment #18)
> There is no confusion, just plain old disagreement. Normally when a bug report
> is filed and the editor agrees and fixes it, it is those who disagree that
> escalate the bug to an issue. I don't see why we should do anything differently
> here, especially given that no one is willing to implement the previous state
> either.
The bug has been reopened (by one of the WG chairs), so it's not in a state
where it can be escalated.
As far as I can tell, the WG waits for the editor to either undo the change, or
to close the bug again.
================================================================================
#20 contributor@whatwg.org 2011-03-01 00:19:04 +0000
--------------------------------------------------------------------------------
Checked in as WHATWG revision r5921.
Check-in comment: revert r5836 per
http://lists.w3.org/Archives/Public/public-html/2011Mar/0002.html
http://html5.org/tools/web-apps-tracker?from=5920&to=5921
================================================================================
#21 Philip Jägenstedt 2011-03-01 08:02:12 +0000
--------------------------------------------------------------------------------
At this point it would be most helpful if implementors at Mozilla and Microsoft
stepped forward to specify exactly what they *are* willing to implement.
As an example of what is missing: do you also intend to respect the codecs
parameter when given in Content-Type?
================================================================================
#22 Philip Jägenstedt 2011-03-03 22:27:09 +0000
--------------------------------------------------------------------------------
OK, new suggestion:
* In most cases, including at least audio/* and video/*, trust the Content-Type
header and try decoding it as such. This is stricter than the current spec,
which requires sniffing after inspecting Content-Type.
* Sniff for the set of Content-Type values that are usually incorrect defaults,
like text/plain and application/octet-stream. The table in
<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02#section-3> looks
relevant to this.
* Ignore the codecs parameter in the Content-Type header completely, since
codec setup cannot be done without inspecting the data anyway.
* Get rid of all special-casing of application/octet-type in canPlayType.
Pros:
* Fixes the biggest problem of Content-Type, namely that videos served as
text/plain or application/octet-stream don't play.
* Respects Content-Type in cases where second guessing likely isn't useful,
like audio/* and video/*.
* Would work the same in a <video> context and in a top-level browsing context.
* Formats that are not reliably sniffable don't have to be added to the
sniffing table, they just wouldn't work when served as
application/octet-stream.
* Browsers that sniff to support existing content (e.g. Safari) would likely
see less breakage than if moving to strict handling like Firefox/IE.
* It's still possible to move to "always sniff" from here without much damage
being left behind.
Cons:
* Inconsistent with how <img> works.
* Requires considering both Content-Type and the data to determine what demuxer
to plug, rather than just one or the other.
* The codecs parameter would have an effect in canPlayType but not in
Content-Type. In practice the codecs parameter isn't sent in Content-Type, so
it's not the end of the world.
================================================================================
#23 Adrian Bateman [MSFT] 2011-03-04 20:12:33 +0000
--------------------------------------------------------------------------------
(In reply to comment #22)
> OK, new suggestion:
>
> * In most cases, including at least audio/* and video/*, trust the Content-Type
> header and try decoding it as such. This is stricter than the current spec,
> which requires sniffing after inspecting Content-Type.
> * Sniff for the set of Content-Type values that are usually incorrect defaults,
> like text/plain and application/octet-stream. The table in
> <http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02#section-3> looks
> relevant to this.
> * Ignore the codecs parameter in the Content-Type header completely, since
> codec setup cannot be done without inspecting the data anyway.
> * Get rid of all special-casing of application/octet-type in canPlayType.
We think we can live with this being what is in the spec. Unfortunately, were
too late to make changes in IE9 (we announced when we shipped the release
candidate that we would be shipping the final release shortly) and as usual I
cant make predictions about when we will adopt things in future releases but
this seems like a reasonable compromise to work towards. As you mention, there
would be an inconsistency between handling of the codecs parameter between
canPlayType compared to playing but this is something we think is necessary
(for example to be able to choose between high and basic profile H.264
streams).
================================================================================
#24 Philip Jägenstedt 2011-03-05 13:11:06 +0000
--------------------------------------------------------------------------------
A few of the things in
<http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects>
are not solved by my new suggestion, so I'd consider not fixing these cons:
* The incentive for supporting many different equivalent MIME types in
canPlayType and <source type> is removed, as they come only from legacy
Content-Type issues.
* Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from
implementations of canPlayType.
This is damage we'll have to live with unless we always sniff, it might be OK
if implementors exercise some contraint in which MIME types they add support
for. WAVE might be a lost case, though.
================================================================================
#25 Yuhong Bao 2011-03-06 07:34:33 +0000
--------------------------------------------------------------------------------
Yea, I remember having to work with Roy Schestowitz of Techrights to fix the
Content-Type when they began using the <video> tag, as one example.
================================================================================
#26 Adrian Bateman [MSFT] 2011-03-07 17:24:52 +0000
--------------------------------------------------------------------------------
(In reply to comment #24)
> A few of the things in
> <http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects>
> are not solved by my new suggestion, so I'd consider not fixing these cons:
>
> * The incentive for supporting many different equivalent MIME types in
> canPlayType and <source type> is removed, as they come only from legacy
> Content-Type issues.
>
> * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from
> implementations of canPlayType.
>
> This is damage we'll have to live with unless we always sniff, it might be OK
> if implementors exercise some contraint in which MIME types they add support
> for. WAVE might be a lost case, though.
I didn't really understand these two points. I'm sure I'm just missing some
background info. Please could you elaborate?
================================================================================
#27 Philip Jägenstedt 2011-03-07 19:56:07 +0000
--------------------------------------------------------------------------------
(In reply to comment #26)
> (In reply to comment #24)
> > A few of the things in
> > <http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects>
> > are not solved by my new suggestion, so I'd consider not fixing these cons:
> >
> > * The incentive for supporting many different equivalent MIME types in
> > canPlayType and <source type> is removed, as they come only from legacy
> > Content-Type issues.
> >
> > * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from
> > implementations of canPlayType.
> >
> > This is damage we'll have to live with unless we always sniff, it might be OK
> > if implementors exercise some contraint in which MIME types they add support
> > for. WAVE might be a lost case, though.
>
> I didn't really understand these two points. I'm sure I'm just missing some
> background info. Please could you elaborate?
It relates to this point from "Issues for Implementors":
* In order to be compatible with what is sent in Content-Type, implementations
must support several synonymous MIME types. This is exposed via canPlayType,
where there was no legacy to consider originally, creating unnecessary room for
incompatibilities. For example, Firefox supports 4 different MIME types for
WAVE, Opera supports 3 and Chrome supports 2. (source:
<http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support>)
If Content-Type was always ignored, this pollution of canPlayType would not
happen. Actually, we could perhaps fix it in my new proposal as well by adding
this point:
* Content-Type is normalized to allow for synonyms like audio/wave and
audio/wav that are necessary for compat, but via canPlayType only the canonical
form is exposed, so only one would return "maybe"/"probably".
I don't think it's actually worth the complexity though, I just consider it a
con relative to ignoring Content-Type.
================================================================================
#28 Adrian Bateman [MSFT] 2011-03-07 20:15:04 +0000
--------------------------------------------------------------------------------
(In reply to comment #27)
> I don't think it's actually worth the complexity though, I just consider it a
> con relative to ignoring Content-Type.
Thanks for the explanation. I agree - I don't think it's worth trying to fix
here either.
================================================================================
#30 Ian 'Hixie' Hickson 2011-10-26 20:48:19 +0000
--------------------------------------------------------------------------------
So what is the spec supposed to say, at this point?
================================================================================
#31 Philip Jägenstedt 2011-10-27 08:26:34 +0000
--------------------------------------------------------------------------------
(In reply to comment #30)
> So what is the spec supposed to say, at this point?
Everyone disagrees on that. I think it should just point to
http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03#section-8 so that
sniffing always takes precedence.
================================================================================
#32 Ian 'Hixie' Hickson 2011-11-02 18:56:05 +0000
--------------------------------------------------------------------------------
If browser vendors disagree on what should happen, then I think I will go back
to strict adherence to the HTTP specs, and then let the market figure it out.
Once browsers converge on a particular behaviour, or once there is agreement on
what they should converge on, I will update the spec to match it.
You are welcome to try to use the escalation process to make a decision sooner,
but of course if it doesn't match what finally gets implemented, it doesn't
much matter what that decision is either. :-)
================================================================================
#33 Philip Jägenstedt 2011-11-03 09:36:20 +0000
--------------------------------------------------------------------------------
(In reply to comment #32)
> If browser vendors disagree on what should happen, then I think I will go back
> to strict adherence to the HTTP specs, and then let the market figure it out.
> Once browsers converge on a particular behaviour, or once there is agreement on
> what they should converge on, I will update the spec to match it.
If we know that browsers are implementing it differently, then I'd much prefer
if the spec made it explicitly undefined and noted that it will be spec'd at
some later point, rather than picking sides up front.
================================================================================
#34 Ian 'Hixie' Hickson 2011-11-03 16:29:23 +0000
--------------------------------------------------------------------------------
I can certainly put a warning in the spec.
================================================================================
#35 contributor@whatwg.org 2011-11-12 00:22:31 +0000
--------------------------------------------------------------------------------
Checked in as WHATWG revision r6826.
Check-in comment: Add warnings about media elements and track and how to
determine the type and how we don't know what hte solution is.
http://html5.org/tools/web-apps-tracker?from=6825&to=6826
================================================================================
#36 Ian 'Hixie' Hickson 2011-11-12 00:30:26 +0000
--------------------------------------------------------------------------------
I've put a warning in the spec. Marking this LATER for now; once browser
vendors have converged on a behaviour or desired behaviour I'll revisit this.
(See comment 32.)
================================================================================
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 September 2012 21:57:42 UTC