Re: [XHR] Content-Length header for data: URLs
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 characters after the , at all. Just applying a multiplying doesn't take percent-escaping into account, though. Right. I guess you can still count that relatively easily, but it's not super straightforward and it's not clear what the benefit of exposing Content-Length is. 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.. -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: URLs
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 http://logbot.glob.com.au/?c=mozilla%23developerss=2+Oct+2013e=2+Oct+2013#c777688 the answer is yes (requiring Content-Length would prevent some implementation strategies). Forgot to report about that discussion here. Thanks for the reminder! -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: URLs
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 characters after the , at all. Just applying a multiplying doesn't take percent-escaping into account, though. Right. I guess you can still count that relatively easily, but it's not super straightforward and it's not clear what the benefit of exposing Content-Length is. -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: URLs
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 desirable/desired/common this is. 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 all. Just applying a multiplying doesn't take percent-escaping into account, though. -- Simon Pieters Opera Software
[XHR] Content-Length header for data: URLs
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: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/data-uri-basic.htm (subtest getAllResponseHeaders()) Current spec text: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http -Hallvord R
Re: [XHR] Content-Length header for data: URLs
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. 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: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/data-uri-basic.htm (subtest getAllResponseHeaders()) Current spec text: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http -Hallvord R -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: [XHR] Content-Length header for data: URLs
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 many use cases but I guess you could easily get a blob from a base64-string, or use it as a more or less convenient XML parser if all you have is a URL-encoded string of XML source text.. :-) Hallvord R.
Re: [XHR] Content-Length header for data: URLs
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 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 pira...@gmail.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... 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. 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: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/data-uri-basic.htm(subtest getAllResponseHeaders()) Current spec text: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http -Hallvord R -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: [XHR] Content-Length header for data: URLs
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: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http Don't know if there are that many use cases but I guess you could easily get a blob from a base64-string, or use it as a more or less convenient XML parser if all you have is a URL-encoded string of XML source text.. :-) The use is where you want to expose a script API that takes a URL. Your API can use XHR on the URL without caring if it's a data: URL, and the user can pass in a data: URL without caring that the innards of the script happen to use XHR with it. It's ordinary layering--the user of your API shouldn't have to care about those things, and you (the author of the API) shouldn't have to worry about avoiding XHR because it'll break data: URLs. -- Glenn Maynard
Re: [XHR] Content-Length header for data: URLs
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. -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: 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) but it looks more like a feature than a bug.. Should we spec it? That would prohibit processing the data URL incrementally. Or at least require you to know the size of it in advance somehow. It's not entirely clear to me whether imposing such a constrain is desirable. -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: URLs
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? -Boris
Re: [XHR] Content-Length header for data: URLs
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 feature than a bug.. Should we spec it? This was added in https://bugzilla.mozilla.org/show_bug.cgi?id=782342 (and in particular due to https://bugzilla.mozilla.org/show_bug.cgi?id=782342#c8). Is the spec treating blob: and data: differently here, or was that comment just wrong? -Boris
Re: [XHR] Content-Length header for data: URLs
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 data: URL is always known as long as you have the entire URL, no? Doesn't that depend on how you end up storing it whether getting that information is fast and easy to get ahead of time? Especially with very large data URLs I thought that might be a concern, but maybe it isn't really as that'd require pretty special strings objects... -- http://annevankesteren.nl/
Re: [XHR] Content-Length header for data: URLs
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 point that data: URL was a string, and you can just save its length in an easy-to-get-to place. -Boris
Re: [XHR] Content-Length header for data: URLs
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 know how much space they're taking up in the storage... But at some point that data: URL was a string, and you can just save its length in an easy-to-get-to place. Indeed, keeping the length accessible seems as easy as keeping the mimetype accessible. / Jonas
Re: [XHR] Content-Length header for data: URLs
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 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 point that data: URL was a string, and you can just save its length in an easy-to-get-to place. -Boris
Re: [XHR] Content-Length header for data: URLs
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 the parts before ','. None of this is all that hard to do. -Boris
Re: [XHR] Content-Length header for data: URLs
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 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 the parts before ','. None of this is all that hard to do. -Boris
Re: [XHR] Content-Length header for data: URLs
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 characters before the , and applying a multiplier parsing. You don't have to look at any characters after the , at all. / Jonas On 20 September 2013 04:58, Boris Zbarsky bzbar...@mit.edu wrote: 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 the parts before ','. None of this is all that hard to do. -Boris
Re: [XHR] Content-Length header for data: URLs
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 ramifications. What I'm seeing here is that being able to have a Content-Length or not seems implementation dependent. Anne is against not taking a stand yet I'm pretty sure we cannot assume all implementations will be able to provide a Content-Length. So it seems like we should just keep prohibiting Content-Length. Do I make sense? On 20 September 2013 05:24, 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 desirable/desired/common this is. 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 all. / Jonas On 20 September 2013 04:58, Boris Zbarsky bzbar...@mit.edu wrote: 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 the parts before ','. None of this is all that hard to do. -Boris
Re: [XHR] Content-Length header for data: URLs
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 dunno the encoding In what situation would this ever happen? What I'm seeing here is that being able to have a Content-Length or not seems implementation dependent. No more so than having a Content-Type, as far as I can see. I'm pretty sure we cannot assume all implementations will be able to provide a Content-Length. I'm pretty sure we can in fact assume just that. So it seems like we should just keep prohibiting Content-Length. If it were useless to provide it, I might agree. But it's useful. This is why blob URIs go out of their way to provide it... -Boris
Re: [XHR] Content-Length header for data: URLs
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 sure we're future-proof in our approach. My opinion is that a Content-Length should be provided but I'm not sure it must. And again, since Anne doesn't seem to favour should... well, we're back at must not. On 20 September 2013 05:55, Boris Zbarsky bzbar...@mit.edu wrote: 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 dunno the encoding In what situation would this ever happen? What I'm seeing here is that being able to have a Content-Length or not seems implementation dependent. No more so than having a Content-Type, as far as I can see. I'm pretty sure we cannot assume all implementations will be able to provide a Content-Length. I'm pretty sure we can in fact assume just that. So it seems like we should just keep prohibiting Content-Length. If it were useless to provide it, I might agree. But it's useful. This is why blob URIs go out of their way to provide it... -Boris
Re: [XHR] Content-Length header for data: URLs
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 can prohibit having a Content-Length when that encoding is used. For now none of the encodings seem to require particularly complicated or expensive logic. So it doesn't seem like an undue burden to require it. / Jonas
Re: [XHR] Content-Length header for data: URLs
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. Does that make sense to others? Sincerely, James Greene On Thu, Sep 19, 2013 at 11: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). I do agree having the Content-Length is useful information, I'm just trying to make sure we're future-proof in our approach. My opinion is that a Content-Length should be provided but I'm not sure it must. And again, since Anne doesn't seem to favour should... well, we're back at must not. On 20 September 2013 05:55, Boris Zbarsky bzbar...@mit.edu wrote: 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 dunno the encoding In what situation would this ever happen? What I'm seeing here is that being able to have a Content-Length or not seems implementation dependent. No more so than having a Content-Type, as far as I can see. I'm pretty sure we cannot assume all implementations will be able to provide a Content-Length. I'm pretty sure we can in fact assume just that. So it seems like we should just keep prohibiting Content-Length. If it were useless to provide it, I might agree. But it's useful. This is why blob URIs go out of their way to provide it... -Boris
Re: [XHR] Content-Length header for data: URLs
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 would likely exclude the comma and prior. Does that make sense to others? Yes. Content-Length is the length of the actual data. -Boris
