On Mon, Oct 7, 2013 at 10:30 PM, Hallvord R. M. Steen
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
http://logbot.glob.com.au/?c=mozilla%23developers&s=2+Oct+2013&e=2+Oct+2013#c7
On Fri, Sep 20, 2013 at 5:09 AM, Simon Pieters wrote:
> On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking 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 characters after the ","
On Fri, Sep 20, 2013 at 5:09 AM, Simon Pieters wrote:
> On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking 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 characters after the "," at
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking wrote:
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg 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
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"
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 Thu, Sep 19, 2013 at 9:10 PM, Julian Aubourg 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 can prohibit
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 sur
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 we
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
ramificati
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg 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 characters
be
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 wrote:
> On 9/19/13 10:51 PM, Julian Aubourg wrote:
>
>> But Content-Length is not t
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 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 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 g
On Thu, Sep 19, 2013 at 6:39 PM, Boris Zbarsky 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 know how
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 poin
On Thu, Sep 19, 2013 at 9:27 PM, Boris Zbarsky 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 data: URL
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?
-Bor
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 feat
On Thu, Sep 19, 2013 at 4:47 PM, Hallvord Steen 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) but it looks
On Thu, Sep 19, 2013 at 7:30 PM, James Greene 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.
--
http://annevankesteren.nl/
On Thu, Sep 19, 2013 at 6:24 PM, Hallvord Steen 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:
> http://dvcs.w3.org/hg/xhr/raw-file/tip/
XHRs for `mailto:`? :)
Kidding, though that would be kind of interesting.
On Sep 19, 2013 6:28 PM, "Jonas Sicking" wrote:
> That's true for too. Technically that's also not
> needed. Same with
>
> I think there's a lot of value in ensuring that all URL schemes work
> in all APIs that handle UR
That's true for too. Technically that's also not
needed. Same with
I think there's a lot of value in ensuring that all URL schemes work
in all APIs that handle URLs. Otherwise the concept of a URL sort of
falls apart.
/ Jonas
On Thu, Sep 19, 2013 at 2:46 PM, pira...@gmail.com wrote:
> Are you
> 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 m
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 :
> Hi,
> I see Gecko "fakes" a Content-Length header (visible to
> getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong
>
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:
27 matches
Mail list logo
