Re: [XHR] Content-Length header for data: URLs

[Boris Zbarsky]

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

Re: [XHR] Content-Length header for data: URLs

[James Greene]

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  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  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

[Jonas Sicking]

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 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

[Julian Aubourg]

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  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

[Boris Zbarsky]

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

[Julian Aubourg]

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  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 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  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

[Jonas Sicking]

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
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  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

[Julian Aubourg]

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 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

[Boris Zbarsky]

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

[Julian Aubourg]

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 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

[Jonas Sicking]

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 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

[Boris Zbarsky]

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

[Anne van Kesteren]

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 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

[Boris Zbarsky]

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

[Boris Zbarsky]

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 
).


Is the spec treating blob: and data: differently here, or was that 
comment just wrong?


-Boris

Re: [XHR] Content-Length header for data: URLs

[Anne van Kesteren]

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 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

[Anne van Kesteren]

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/

Re: [XHR] Content-Length header for data: URLs

[Glenn Maynard]

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/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

[James Greene]

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 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 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
> 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

[Jonas Sicking]

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 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 
>> 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

[Hallvord Steen]

> 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: [webcomponents]: The Shadow Cat in the Hat Edition

[Tab Atkins Jr.]

On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov  wrote:
> Part 1: Revenge of the :host
>
> Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
> where we decided that shadow host could be matched by both outer and
> inner trees 
> (http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
> first point), we quickly coded this up in Blink and gave it to Mikey
> ...erm, the Polymer folks to chew on.
>
> The folks spat out that morsel right across the table
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
> good arguments to justify their etiquette faux pas.
>
> For what it's worth, it would be fairly easy to make shadow tree rules
> match shadow host only when ":host" is present in a rule.
>
> Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
> state, since addressing these arguments makes it harder to keep a
> straight face with the concept of a pseudo class in regard to :host.
> See discussion on bug for the gory details.
>
> As of now, we are in that angsty state of not knowing what to do next.
> Any ideas are appreciated. Note that there are some well-established
> concepts in CSS and inventing fewer new concepts is much preferred.
> Reuse, reduce, recycle.

Some in-person discussion led to an elegant solution:  keep the host
element in the set of elements, but neuter all of its features. As far
as the selectors in the shadow root can see, it's a node with no
tagname, no id, no classes, etc.  The one and only thing that will
match it is :host and :host().  (And *, of course.)

Also, just in case it wasn't clear earlier, :host() only matches the
host element.  Like :drop/:drop(), the non-function version is just
the "widest possible" version of the functional version - it always
matches the host, while ":host(sel)" only matches the host if
something in the ancestor tree matches "sel".

Here's an example:


  
[shadow-root]
  some text!
  
div { ... } // matches the div.bar
:host { ... } // matches the x-dialog
x-dialog { ... } // matches nothing...
// there's no node named "x-dialog" viewable from here
  
  


> Part 2: Party ::part part
>
> Another possible wrinkle is the ::part pseudo element. After also
> chewing on ::part for a little while, our brave guinea pi.. erm,
> people also declared it to be tasting somewhat bitter.
>
> The best symptom can be seen here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
> that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
> to cross each shadow tree boundary, the guinea people looked at me
> like this: <_<. Then they pointed out that this both:
>
> a) implies ever-growing "part" API for each component, which will
> quickly lead to the anti-pattern of developers simply declaring all
> elements in their shadow tree as parts, and
>
> b) just looks ugly and constipated.
>
> Agitated shouts of "Y U NO LET US JUS DO EET" were echoing across the
> San Francisco Bay, frightening America's Cup spectators.
>
> To calm the brave guinea people down, I showed them a magic trick. Out
> of my sleeve, I pulled out two new combinators: A hat (^) and a cat
> (^^).
>
> You would use them instead of ::part. The hat is generally equivalent
> to a descendant combinator, except it crosses 1 (one) shadow tree
> boundary (from shadow host to shadow root). The cat is similar, except
> it crosses any number of boundaries. So, to target "bler" in the
> previous part-y chain could be written as simply as
> x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
> part="bler" attribute. Respectively, you would target "woot" as simply
> x-nurk^#woot.
>
> But wait there's more: you could use these new combinators in
> querySelector, I proclaimed! In the nascent shadow DOM code, we
> already started seeing the blood-curling
> document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
> chains of hell -- a problem that these new combinators would solve.
>
> Think of them simply general combinators that opens shadow trees for
> selector traversal, just like Element.shadowRoot did for DOM
> traversal.
>
> The brave guinea people became content and reverted to their natural
> behaviors, but I then started worrying. Did I over-promise and finally
> ruined encapsulation? When will our styling woes finally converge into
> one solution?
>
> Luckily, I have you, my glorious WebApp-erators. Put on your thinking
> hats and help find one uniform solution. Something that fits well into
> CSS, doesn't add too many new moving parts, and keeps the brave guinea
> people at bay. That'll be the day.

In-person discussion convinced me of the use of this.  Basically, we
should go ahead and expose a nice, wide feature now, rather than
trying to expose one that is locked down *just right*.  We can add
more features that are harder to misuse in the future, once we have a
better idea of the common usage patterns

Re: [XHR] Content-Length header for data: URLs

[pira...@gmail.com]

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 
> 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

[XHR] Content-Length header for data: URLs

[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 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: [webcomponents]: The Shadow Cat in the Hat Edition

[Steve Orvell]

For context here's another thread about ::part where we start to look a
little into the rabbit hole:

http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0012.html

One wants the expressiveness of css applied to ::part but things get
complicated very fast and the 'shadow cat' starts to look a lot more
appealing.