- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 20 May 2010 18:10:02 +0800
On Thu, 20 May 2010 17:59:42 +0800, Robert O'Callahan <robert at ocallahan.org> wrote: > On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan > <robert at ocallahan.org>wrote: > >> I just became aware that application/octet-stream is excluded from >> being a >> type "the user agent knows it cannot render". >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render >> Apparently this was done in response to a bug report: >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977 >> Neither the bug report nor the editor's response give any indication why >> this change was made. >> >> This change means files served with application/octet-stream will make >> it >> all the way to the step "If the media >> data<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data>can >> be fetched but is found by inspection to be in an unsupported format >> ...", so implementations have to add support for binary sniffing for >> all the >> types they support. We didn't need this before in Gecko. What was the >> motivation for adding this implementation requirement? >> > > Hmm. I guess it doesn't add any implementation requirements beyond what > you > need to handle the complete absence of a Content-Type (which we currently > don't handle, but I suppose we should). So this isn't really a problem. > > I'd still like to know why application/octet-stream has been added here, > though. For the record, Opera implements canPlayType("application/octet-stream") and canPlayType("application/octet-stream; codecs=foo") as per spec ("maybe" and "" respectively), but I don't have any strong opinions about it. -- Philip J?genstedt Core Developer Opera Software
Received on Thursday, 20 May 2010 03:10:02 UTC