Long story short: I haven't changed the spec where it talks about video,
source type, Content-Type, and direct file inspection for type
determination. My plan is to just wait and see what browsers do and update
the spec accordingly in due course. This is mostly because we clearly have
a wide
On 12/8/10 8:19 PM, Ian Hickson wrote:
You can't sniff in a toplevel browser window. Not the same way that
people are sniffing invideo. It would break the web.
How so?
People actually rely on the not-sniffing behavior of UAs in actual
browser windows in some cases. For example,
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
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
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as official.
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
current rendering is best effort if any
On 2010-09-13 15:55, Nils Dagsson Moskopp wrote:
Mikko Rantalainenmikko.rantalai...@peda.net schrieb am Mon, 13 Sep
2010 16:03:27 +0300:
[…]
Basically, this sounds like all the issues of BOM for all binary
files.
And why do we need this? Because web servers are not behaving
correctly and
On 2010-09-14 08:37, Julian Reschke wrote:
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as official.
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
2010-09-11 01:51 EEST: Roger Hågensen:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
For at least WAVE, Ogg and WebM it's not possible as they begin with
different magic bytes.
Then why not define a new magic that is universal, so that if a proper
content type is not stated then a sniffing
On 2010-09-13 15:03, Mikko Rantalainen wrote:
2010-09-11 01:51 EEST: Roger Hågensen:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
For at least WAVE, Ogg and WebM it's not possible as they begin with
different magic bytes.
Then why not define a new magic that is universal, so that if a
Mikko Rantalainen mikko.rantalai...@peda.net schrieb am Mon, 13 Sep
2010 16:03:27 +0300:
[…]
Basically, this sounds like all the issues of BOM for all binary
files.
And why do we need this? Because web servers are not behaving
correctly and are sending incorrect Content-Type headers? What
On Mon, Sep 13, 2010 at 9:03 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
For any other value of Content-Type, honor the type specified in HTTP
level. And provide no overrides of any kind on any level above the HTTP.
Levels above HTTP may provide HINTS about the content that can be
On 2010-09-11 03:40, Silvia Pfeiffer wrote:
[snip...]
And yeah, this kinda stretched beyond the scope of HTML5 specs,
but you'd be swatting two flies at once, solving the sniffing
issue with video and audio, but also the sniffing issue that
every OS has had for the last couple
On 2010-09-09 09:24, Philip Jägenstedt wrote:
On Thu, 09 Sep 2010 02:15:27 +0200, David Singer sin...@apple.com
wrote:
On Wed, Sep 8, 2010 at 3:13 PM, And Clover and...@doxdesk.com wrote:
Perhaps I *meant* to serve a non-video
file with something that looks a fingerprint from a video format
On Sat, Sep 11, 2010 at 8:51 AM, Roger Hågensen resca...@emsai.net wrote:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
On Thu, 09 Sep 2010 02:15:27 +0200, David Singer sin...@apple.com
wrote:
On Wed, Sep 8, 2010 at 3:13 PM, And Clover and...@doxdesk.com wrote:
Perhaps I *meant* to
I think we should always sniff or never sniff, for simplicity.
Philip
On Wed, 08 Sep 2010 19:14:48 +0200, David Singer sin...@apple.com wrote:
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the
purposes of
I can't think why always sniffing is simple, or cheap, or desirable. I'd love
to get to never-sniff, but am not sanguine.
On Sep 9, 2010, at 0:07 , Philip Jägenstedt wrote:
I think we should always sniff or never sniff, for simplicity.
Philip
On Wed, 08 Sep 2010 19:14:48 +0200, David
Much of this discussion has focused on the careless server operator. What
about the careful ones?
Given the past history of content sniffing and security warts, it is useful
- or at least comforting - to have a path for the careful server to indicate
I know this file really is intended to be
On Sep 9, 2010, at 16:38 , Andy Berkheimer wrote:
Much of this discussion has focused on the careless server operator. What
about the careful ones?
Given the past history of content sniffing and security warts, it is useful -
or at least comforting - to have a path for the careful
On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only
On 07.09.2010 22:00, Boris Zbarsky wrote:
...
* If a file in a top-level browsing context is sniffed as video but
then some kind of error is returned before the video plays the first
frame, fall back to allowing the user to download it, or whatever the
usual action would be if no sniffing had
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the purposes of
determining CanPlay, dispatch, if the HTML source gave you a mime type?
On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote:
On Tue, 07 Sep 2010
On 9/8/10 11:05 AM, Julian Reschke wrote:
It's not that hard if it's acceptable to restart the network request
(just do it again, with a flag not-to-sniff).
It's common enough to not be ok to restart, though. And even the
restart behavior can be pretty complicated, since it requires not just
On 09/07/2010 09:29 PM, Aryeh Gregor wrote:
I'm not a fan of sniffing, but I'm also not a fan of blindly believing
clearly wrong MIME types
Who decides what is clearly wrong? Perhaps I *meant* to serve a
non-video file with something that looks a fingerprint from a video
format at the top.
On Tue, Sep 7, 2010 at 4:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only if
On 9/8/10 3:58 PM, Aryeh Gregor wrote:
And the problem is that you don't want to keep the data handy in case
it fails?
Yes. The problem is that I don't want to have to buffer up
potentially-arbitrary amounts of data.
Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as
On Sep 8, 2010, at 12:58 , Aryeh Gregor wrote:
On Wed, Sep 8, 2010 at 1:14 PM, David Singer sin...@apple.com wrote:
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the purposes of
determining CanPlay,
On Tue, 07 Sep 2010 02:46:29 +0200, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Mon, Sep 6, 2010 at 3:19 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedt phil...@opera.com
wrote:
The Ogg page begins with the 4 bytes OggS, which is what
On Tue, 07 Sep 2010 03:56:54 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/6/10 3:19 PM, Aryeh Gregor wrote:
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedtphil...@opera.com
wrote:
The Ogg page begins with the 4 bytes OggS, which is what Opera
(GStreamer)
checks for. For additional
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
Sniffing is a perpetual disaster that, after several
On 07.09.2010 11:51, And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
+1
Sniffing is
On Tue, 07 Sep 2010 11:51:55 +0200, And Clover and...@doxdesk.com wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it
On 07.09.2010 12:52, Philip Jägenstedt wrote:
...
IE9, Safari and Chrome ignore Content-Type in a video context and rely
on sniffing. If you want Content-Type to be respected, convince the
developers of those 3 browsers to change. If not, it's quite inevitable
that Opera and Firefox will
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for missing
Content-Type, text/plain and application/octet-stream.
That's not what at least Aryeh is proposing, no. Also
On 9/7/10 6:01 AM, Julian Reschke wrote:
Hmm, that's what Content-Disposition: attachment is for...
This header is currently ignored in non-toplevel browsing contexts in
web browsers, last I checked.
-Boris
On 9/7/10 4:11 AM, Philip Jägenstedt wrote:
It's garbage in at least UTF-8, Big5 and GBK.
Thanks. I assume that applies to the OggS\0 sequence too, right? I
appreciate the data!
I'm not sure what infrastructure is in place, but perhaps one could
*not* sniff if Content-Type also indicates
On Tue, 07 Sep 2010 14:54:15 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for missing
Content-Type, text/plain and
On 9/7/10 9:03 AM, Philip Jägenstedt wrote:
On Tue, 07 Sep 2010 14:54:15 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for
On Tue, 07 Sep 2010 14:56:38 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 4:11 AM, Philip Jägenstedt wrote:
It's garbage in at least UTF-8, Big5 and GBK.
Thanks. I assume that applies to the OggS\0 sequence too, right? I
appreciate the data!
UTF-8, Big5 and GBK are all (as
On 9/7/10 9:16 AM, Philip Jägenstedt wrote:
UTF-8, Big5 and GBK are all (as far as I know) ASCII supersets. Do
real-world text documents include \0 bytes?
Yes. Real-world text documents include all sorts of gunk. Just rarely.
As long as indicates an encoding doesn't include UTF-8 or
On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote:
On Tue, 07 Sep 2010 11:51:55 +0200, And Clover and...@doxdesk.com wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone
On Sep 7, 2010, at 2:51 , And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
Yes. We
And like I said before, please be careful of assuming our intent and desires
from the way things currently work. We are thinking, listening, and
implementing (and fixing bugs, and re-inspecting older behavior in lower-level
code), so there is some...flexibility...I think.
On Sep 7, 2010, at
On Tue, Sep 7, 2010 at 3:01 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 07.09.2010 11:51, And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for
On 9/7/10 3:19 PM, Adam Barth wrote:
It sadden me when standards bodies ignore reality and leave
implementors to invent their own non-iteroperable algorithms for
security-critical behavior.
Of course nothing prevents us from saying UAs MUST NOT sniff but if they
do anyway they MUST use a
On Tue, Sep 7, 2010 at 5:51 AM, And Clover and...@doxdesk.com wrote:
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
I'm not a fan of sniffing, but I'm also not a fan of blindly believing
clearly wrong MIME types and
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only if the encoding is
either not present or is UTF-8 or ISO-8859-1. Or
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only if the encoding is
either not present or is UTF-8 or ISO-8859-1. Or
On Tue, Sep 7, 2010 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 3:19 PM, Adam Barth wrote:
It sadden me when standards bodies ignore reality and leave
implementors to invent their own non-iteroperable algorithms for
security-critical behavior.
Of course nothing prevents us
Of course nothing prevents us from saying UAs MUST NOT sniff but if they do
anyway they MUST use a given algorithm, right?
That's a contrary to duty imperative, which is something that's been
puzzling philosophers for centuries. A more sensible requirement
would be that user agents SHOULD NOT
On Tue, Sep 7, 2010 at 2:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Of course nothing prevents us from saying UAs MUST NOT sniff but if they
do
anyway they MUST use a given algorithm, right?
That's a contrary to duty imperative, which is something that's been
puzzling philosophers for
On 9/7/10 5:35 PM, Adam Barth wrote:
In any case, lawyering the requirement level in the spec isn't the way
to solve these problems. You need to change the underlying incentives
to actually affect what gets implemented.
The incentive structure for pretty much any sort of sniffing is a
On Sun, 05 Sep 2010 21:59:09 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Fri, Sep 3, 2010 at 11:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Is this a reasonable supposition? What are these byte sequences for the
container formats at hand? (Say WebM's restricted Matroska
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedt phil...@opera.com wrote:
The Ogg page begins with the 4 bytes OggS, which is what Opera (GStreamer)
checks for. For additional safety, one could also check for the trailing
version indicator, which ought to be a NULL byte for current Ogg. [1]
On Mon, Sep 6, 2010 at 3:19 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedt phil...@opera.com wrote:
The Ogg page begins with the 4 bytes OggS, which is what Opera (GStreamer)
checks for. For additional safety, one could also check for the
On Fri, Sep 3, 2010 at 5:05 PM, David Singer sin...@apple.com wrote:
Um, I think that in some cases the code that is supporting video/audio has
... historical artefacts ... which may not be entirely in line with the
specs. I think it's dangerous to make assumptions in this area, especially
On Thu, Sep 2, 2010 at 4:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Well, serving up data as text/plain for it to be readable is one. I agree
that for the specific case of video this is not a big deal.
Yes, I'm talking specifically about that. Sniffing in other cases (in
particular, text
On Sep 3, 2010, at 12:48 , Aryeh Gregor wrote:
Er... Where did I propose this? I proposed speccing that there MUST NOT be
any sniffing, with browsers that sniff therefore being nonconformant. I
didn't propose allowing ad-hoc sniffing.
Right. But the spec never allowed sniffing, and two
On 9/3/10 3:48 PM, Aryeh Gregor wrote:
Why are you assuming that?
Because blocking an entire MIME type seems like it would be massive
overkill . . . but if that's a real use-case, well, okay. It still
can't be *too* hard to check the first few bytes of the contents.
They must do it anyway if
On Thu, Sep 2, 2010 at 12:21 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/1/10 4:46 PM, Aryeh Gregor wrote:
Is this realistically possible unless the author deliberately crafts
the file?
I'm not an audio/video format expert; I have no idea. Does it matter?
Yes. If false positives were
On 9/2/10 3:53 PM, Aryeh Gregor wrote:
Why is it not a problem if there are suddenly use cases that are impossible
because the browser will ignore the author's intent?
Which use-cases?
Well, serving up data as text/plain for it to be readable is one. I
agree that for the specific case of
On Tue, 31 Aug 2010 09:36:00 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 19 Jul 2010, Philip Jägenstedt wrote:
I've tested Firefox 3.6.4, Firefox 4.0b1 and Chrome 5.0.375.99 and none
return maybe for canPlayType(application/octet-stream). I couldn't
get meaningful results from Safari on
On Wed, 01 Sep 2010 02:59:54 +0200, Andrew Scherkus
scher...@chromium.org wrote:
On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky bzbar...@mit.edu
wrote:
You can't sniff in a
On Aug 31, 2010, at 9:40 AM, Boris Zbarsky wrote:
On 8/31/10 3:36 AM, Ian Hickson wrote:
You might say Hey, but aren't you content sniffing then to find the
codecs and you'd be right. But in this case we're respecting the MIME
type sent by the server - it tells the browser to whatever level
On 9/1/10 4:12 AM, Philip Jägenstedt wrote:
If we start ignoring the Content-Type I expect we would also add
sniffing so that opening a video served with the wrong (or missing)
Content-Type still works in a top-level browsing context, as it does for
images (I think).
It can't possibly work for
On Wed, 01 Sep 2010 15:14:10 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/1/10 4:12 AM, Philip Jägenstedt wrote:
If we start ignoring the Content-Type I expect we would also add
sniffing so that opening a video served with the wrong (or missing)
Content-Type still works in a top-level
On 9/1/10 10:23 AM, Philip Jägenstedt wrote:
Huh, I guessed incorrectly, neither serving a PNG as text/plain or
text/html makes it be sniffed and rendered in a top-level browsing
context in Opera. However, both work in IE8.
Why do you say that it can't possibly work?
That was a statement
On 9/1/10 9:13 AM, Brian Campbell wrote:
It seems that periodically, web standards bodies decide this time, if we're strict,
people will just get the content right or it won't work (such as XHTML with XML
parsing rules), and invariably, people manage to screw it up anyhow. Sure, when the
On 01.09.2010 10:12, Philip Jägenstedt wrote:
...
If we start ignoring the Content-Type I expect we would also add
sniffing so that opening a video served with the wrong (or missing)
Content-Type still works in a top-level browsing context, as it does for
images (I think).
...
Sniffing in the
On 01.09.2010 16:23, Philip Jägenstedt wrote:
...
Huh, I guessed incorrectly, neither serving a PNG as text/plain or
text/html makes it be sniffed and rendered in a top-level browsing
context in Opera. However, both work in IE8.
...
Please don't say work when talking about something that's not
On 01.09.2010 15:13, Brian Campbell wrote:
On Aug 31, 2010, at 9:40 AM, Boris Zbarsky wrote:
On 8/31/10 3:36 AM, Ian Hickson wrote:
You might say Hey, but aren't you content sniffing then to find the
codecs and you'd be right. But in this case we're respecting the MIME
type sent by the server
On 1 Sep 2010, at 15:45, Julian Reschke wrote:
The big problem with MIME types is that they don't stick to files very well.
So, while someone might get them working when they initially use video, if
they move to a different web server, or upgrade their server, or someone
mirrors their
On Wed, Sep 1, 2010 at 10:51 AM, Adrian Sutton adrian.sut...@ephox.com wrote:
Given that there is a very limited set of video formats that are supported
anyway, wouldn't it be reasonable to just identify or define the standard
file extensions then work with server vendors to update their
On Aug 31, 2010, at 4:01 PM, Ian Hickson wrote:
On Tue, 31 Aug 2010, Eric Carlson wrote:
On Aug 31, 2010, at 12:36 AM, Ian Hickson wrote:
Safari does crazy things right now that we won't go into; for the
purposes of this discussion we'll assume Safari can change.
What crazy things does
On Sep 1, 2010, at 9:07 AM, Zachary Ozer wrote:
On Wed, Sep 1, 2010 at 10:51 AM, Adrian Sutton adrian.sut...@ephox.com
wrote:
Given that there is a very limited set of video formats that are supported
anyway, wouldn't it be reasonable to just identify or define the standard
file extensions
On Wed, Sep 1, 2010 at 12:29 PM, Eric Carlson eric.carl...@apple.com wrote:
Hard coding the type is only possible if the element uses a source
element, @type isn't allowed on audio or video.
Why isn't type allowed for video and audio? I know it doesn't
strictly make sense (since the tag
On Wed, 1 Sep 2010, Julian Reschke wrote:
On 01.09.2010 16:23, Philip Jägenstedt wrote:
...
Huh, I guessed incorrectly, neither serving a PNG as text/plain or
text/html makes it be sniffed and rendered in a top-level browsing
context in Opera. However, both work in IE8.
Please don't
On 9/1/10 2:51 PM, Ian Hickson wrote:
(Currently, text/html won't ever sniff as binary IIRC, but text/plain, in
certain cases, will.
Will sniff as binary so as not to render as text but will NOT, last I
checked, render as an image or whatnot (for good security reasons, imho).
-Boris
On Tue, Aug 31, 2010 at 4:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The issue would be someone linking to text or HTML or a binary blob that
happens to have some bits at the beginning that look like an audio/video
types and expecting them to be rendered respectivel as text or HTML or be
On Thu, Sep 2, 2010 at 12:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/1/10 9:13 AM, Brian Campbell wrote:
It seems that periodically, web standards bodies decide this time, if
we're strict, people will just get the content right or it won't work (such
as XHTML with XML parsing rules),
On 9/1/10 10:59 PM, Silvia Pfeiffer wrote:
I hasn't actually happened for MIME types in toplevel documents
(modulo the one known workaround for a common server issue with
text/plain). By and large, browsers don't sniff toplevel browsing
contexts, and the one browser that does
On 9/1/10 4:46 PM, Aryeh Gregor wrote:
On Tue, Aug 31, 2010 at 4:13 PM, Boris Zbarskybzbar...@mit.edu wrote:
The issue would be someone linking to text or HTML or a binary blob that
happens to have some bits at the beginning that look like an audio/video
types and expecting them to be rendered
Quick terminology point: in this e-mail, I use the term sniff to mean
examine the first few bytes of a resource, and determine its type
heuristically in contrast with assuming that the type of a file is that
given by its MIME type (or, heaven forfend, the file extension).
On Thu, 20 May 2010,
On 31.08.2010 09:36, Ian Hickson wrote:
Fromhttp://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.1:
Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of meaningful
parameters depends on the media type and subtype. Most
On 8/31/10 3:36 AM, Ian Hickson wrote:
You might say Hey, but aren't you content sniffing then to find the
codecs and you'd be right. But in this case we're respecting the MIME
type sent by the server - it tells the browser to whatever level of
detail it wants (including codecs if needed) what
Devil's advocate.
On Tue, 31 Aug 2010 15:40:18 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/31/10 3:36 AM, Ian Hickson wrote:
The Microsoft guys responded to my suggestion that they might want to
implement something like this with what's the benefit of doing that?.
One obvious benefit
On 31.08.2010 15:57, Anne van Kesteren wrote:
...
Another is that when you save the video to disk the browser will fix
up the extension correctly, if needed.
If you sniff you can fix it up correctly too.
...
Then let's hope that sniffing doesn't recognize Windows binaries.
Best regards,
On Tue, Aug 31, 2010 at 3:36 AM, Ian Hickson i...@hixie.ch wrote:
The Microsoft guys responded to my suggestion that they might want to
implement something like this with what's the benefit of doing that?.
It's a tough question, in this context, given that there's no possibilty
of script
On 8/31/10 3:59 PM, Aryeh Gregor wrote:
On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarskybzbar...@mit.edu wrote:
You can't sniff in a toplevel browser window. Not the same way that people
are sniffing invideo. It would break the web.
How so? For the sake of argument, suppose you sniff only
On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky bzbar...@mit.edu wrote:
You can't sniff in a toplevel browser window. Not the same way that
people
are sniffing in video. It would
On 8/31/10, Aryeh Gregor simetrical+...@gmail.com wrote:
If you can't come up with any actual problems with what IE is doing,
then why is anything else even being considered? There's a very
clear-cut problem with relying on MIME types: MIME types are often
wrong and hard for authors to
On Tue, Aug 31, 2010 at 9:27 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On 8/31/10, Aryeh Gregor simetrical+...@gmail.com wrote:
If you can't come up with any actual problems with what IE is doing,
then why is anything else even being considered? There's a very
clear-cut problem with
On 18.08.2010 13:47, Julian Reschke wrote:
In the meantime, Ian did some test, see
http://krijnhoetmer.nl/irc-logs/whatwg/20100819#l-28
and
http://hixie.ch/tests/adhoc/html/video/001.html
Ian, any chance you could tests for *absent* content type?
Best regards, Julian
On 20.05.2010 20:53, Simon Pieters wrote:
On Thu, 20 May 2010 20:18:43 +0200, David Singer sin...@apple.com wrote:
It's an error to have a parameter that isn't valid for the mime type,
so are you suggesting (a) that you throw away the parameter as it's
invalid or (b) since it's an error to
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:
On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
I just became aware that application/octet-stream is excluded from being a
type the user agent knows it cannot render.
On Thu, 20 May 2010 17:59:42 +0800, Robert O'Callahan
rob...@ocallahan.org wrote:
On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
I just became aware that application/octet-stream is excluded from
being a
type the user agent knows it cannot render.
On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:
I just became aware that application/octet-stream is excluded from being
a
type the user agent knows it cannot render.
On Thu, 20 May 2010 12:36:36 +0200, Simon Pieters sim...@opera.com wrote:
On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:
I just became aware that application/octet-stream is excluded from
being a
type the user agent knows it cannot render.
On Thu, 20 May 2010 12:46:16 +0200, Simon Pieters sim...@opera.com wrote:
On Thu, 20 May 2010 12:36:36 +0200, Simon Pieters sim...@opera.com
wrote:
On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:
I just became aware that application/octet-stream is
On 5/20/10 5:59 AM, Robert O'Callahan wrote:
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).
For what it's worth, the above-necko layer in Gecko never
1 - 100 of 105 matches
Mail list logo
