On Fri, Sep 20, 2013 at 5:09 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:
I would hardly call taking the length subtracting any characters
before the , and applying a multiplier parsing. You don't have to
look at any
On Mon, Oct 7, 2013 at 10:30 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
So - did we reach some consensus on this question? I would like to know if I
should report a bug on removing this functionality from Gecko or not..
Per
On Fri, Sep 20, 2013 at 5:09 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:
I would hardly call taking the length subtracting any characters
before the , and applying a multiplier parsing. You don't have to
look at any
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net wrote:
Sure, what I actually meant is that you'd need to somehow pre-parse the
data
URL to extract the exact length before storage. Dunno how
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong per
the spec (which is explicitly requiring only a single Content-Type response
header) but it looks more like a feature than a bug.. Should we spec it?
Test:
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
2013/9/19 Hallvord Steen hst...@mozilla.com:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR.
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
You can indeed, in browsers that (more or less) support spec:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http
Don't know if there are that
XHRs for `mailto:`? :)
Kidding, though that would be kind of interesting.
On Sep 19, 2013 6:28 PM, Jonas Sicking jo...@sicking.cc wrote:
That's true for img src=data:... too. Technically that's also not
needed. Same with img src=blob:...
I think there's a lot of value in ensuring that all
On Thu, Sep 19, 2013 at 6:24 PM, Hallvord Steen hst...@mozilla.com wrote:
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
You can indeed, in browsers that (more or less) support spec:
On Thu, Sep 19, 2013 at 7:30 PM, James Greene james.m.gre...@gmail.com wrote:
XHRs for `mailto:`? :)
Kidding, though that would be kind of interesting.
That gives a network error when fetching. See
http://fetch.spec.whatwg.org/ You can only navigate to mailto URLs.
--
On Thu, Sep 19, 2013 at 4:47 PM, Hallvord Steen hst...@mozilla.com wrote:
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong
per the spec (which is explicitly requiring only a single Content-Type
response header)
On 9/19/13 8:52 PM, Anne van Kesteren wrote:
That would prohibit processing the data URL incrementally. Or at least
require you to know the size of it in advance somehow.
I'm not sure I follow. The size of the data for a data: URL is always
known as long as you have the entire URL, no?
On 9/19/13 4:47 PM, Hallvord Steen wrote:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong per the spec
(which is explicitly requiring only a single Content-Type response header) but it looks
more like a
On Thu, Sep 19, 2013 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 8:52 PM, Anne van Kesteren wrote:
That would prohibit processing the data URL incrementally. Or at least
require you to know the size of it in advance somehow.
I'm not sure I follow. The size of the data for a
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast and easy to get ahead of time?
I suppose, if you store them somewhere where you don't know how much
space they're taking up in the storage... But at some
On Thu, Sep 19, 2013 at 6:39 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast and easy to get ahead of time?
I suppose, if you store them somewhere where you don't
But Content-Length is not the same as the length of the string containing
the Data URL.
On 20 September 2013 03:39, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But Content-Length is not the same as the length of the string
containing the Data URL.
Sure. It can also be a simple formula computed from that length, in the
case of base64-encoded data URLs.
And of course you have to subtract out the length of
Sure, what I actually meant is that you'd need to somehow pre-parse the
data URL to extract the exact length before storage. Dunno how
desirable/desired/common this is.
On 20 September 2013 04:58, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net wrote:
Sure, what I actually meant is that you'd need to somehow pre-parse the data
URL to extract the exact length before storage. Dunno how
desirable/desired/common this is.
I would hardly call taking the length subtracting any
Well, it's not rocket-science for sure but we do need to parse the part
before the ,. We need to check the encoding, we need to make sure we know
how to determine the actual length for this encoding, we need a way to not
store length if we dunno the encoding. Simple enough but has some
On 9/19/13 11:39 PM, Julian Aubourg wrote:
We need to check the encoding
You mean the base64 or lack thereof?
we need to make sure we
know how to determine the actual length for this encoding
For base64 you do. Otherwise, it's a malformed data URI.
we need a way
to not store length if
It's a malformed data URI for now. What I'm wondering is if we're sure
we'll never have an encoding that makes it impossible to determine the
length without decoding the entire content (think url-encoded like).
I do agree having the Content-Length is useful information, I'm just trying
to make
On Thu, Sep 19, 2013 at 9:10 PM, Julian Aubourg j...@ubourg.net wrote:
It's a malformed data URI for now. What I'm wondering is if we're sure we'll
never have an encoding that makes it impossible to determine the length
without decoding the entire content (think url-encoded like).
If we do, we
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length would likely
exclude the comma and prior.
On 9/20/13 1:05 AM, James Greene wrote:
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length
26 matches
Mail list logo
