Re: [CORS] Applying preflight cache to an entire domain?

[Monsur Hossain]

Thanks for the clarification, that makes sense.

A little background on why I'm thinking about this. I've been investigating
CORS performance on mobile. Mobile is a great use case for CORS since it is
mostly guaranteed to be supported (at least on iOS and Android). However,
the cost of making two HTTP requests per logical request can be expensive,
especially in a mobile environment.

The preflight cache is keyed on the origin/url pair. Furthermore, Chrome
includes a max-preflight time on 5 minutes (not sure if other browsers do
the same). So in an ideal scenario, the browser will be making one
preflight request every 5 minutes.

That doesn't sound so bad, but consider a typical RESTful API, where each
resource is represented by a different url. The preflight cache will yield
a cache hit in very narrow situations (perhaps while updating the same
resource over and over again, or polling a particular endpoint).

So I'm concerned that the cache-hit ratio in real world applications will
actually be quite low. It would be nice to have some sort of solution to
this.

Thanks,
Monsur


On Wed, Apr 18, 2012 at 11:50 AM, Anne van Kesteren wrote:

> On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain 
> wrote:
>
>> Ah thank you! I agree that url canonicalization is a difficult issue to
>> solve. FWIW, I was envisioning something much simpler. The CORS spec makes
>> it clear that cache lookup should be done by origin and request url. So
>> instead of specifying a url to this Access-Control-Policy-Path header, it
>> would be just one of three values:
>>
>>   - "url" - (default behavior) Cache lookup is done by origin and request
>>
>>   url, as the spec indicates now
>>   - "origin" - Cache lookup is done by origin only. Preflight response
>>
>>   applies to any request from this origin.
>>   - "any" - Cache lookup applies to *any* origin making requests to the
>>
>>   domain.
>>
>> This would fit in with the current preflight caching model while still
>> allowing some flexibility to servers implementing CORS.
>>
>
> The reason why we wanted it scoped was because people had concerns about
> giving any URL on a server control over which other resources would end up
> being shared. The scenarios typically involved large organizations with
> many different teams operating on a single origin. If one of those teams
> thinks sharing with everyone is fine, the rest can be comprised. And such a
> mistake is rather easy to make.
>
> Another general concern that has been frequently raised and why the
> specification has so many flags for enabling additional features such as
> headers and methods, is that people easily shoot themselves in the foot.
> Your proposal makes it rather easy for them to shoot themselves in the foot.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 10:02 AM, Marcos Caceres
wrote:

> On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote:
>  > thanks Marcos, I drop my objection; regarding the reference to HTML5,
>
> Yay! :)
> > it would be an improvement if you could change section 6.5 from:
> >
> > The concept of origin is defined in [HTML] (
> http://dev.w3.org/2006/waf/widgets-api/#html5).
> >
> > to
> >
> > The concept of origin of a Document object is defined in [HTML] (
> http://dev.w3.org/2006/waf/widgets-api/#html5).
> Done, and committed:
> http://dev.w3.org/2006/waf/widgets-api/#origin


thanks for the "speed of light" resolution! :)

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote:

> 
> thanks Marcos, I drop my objection; regarding the reference to HTML5,

Yay! :)  
> it would be an improvement if you could change section 6.5 from: 
> 
> The concept of origin is defined in [HTML] 
> (http://dev.w3.org/2006/waf/widgets-api/#html5). 
> 
> to
> 
> The concept of origin of a Document object is defined in [HTML] 
> (http://dev.w3.org/2006/waf/widgets-api/#html5). 
Done, and committed:
http://dev.w3.org/2006/waf/widgets-api/#origin

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:49 AM, Marcos Caceres  wrote:

> On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote:
> > On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:
> >
> > > > in that case, please record an objection on my part
> > > just to be clear, I mean an objection to publishing as PR unless this
> is clarified; i believe this is an issue because the concept and use of
> origin is (1) very complex and (2) thus prone to misinterpretation; for
> example, it is not well recognized that HTML5 itself does not require a UA
> to send an Origin header in a URL request (see [3])
> > Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web
> Storage). But what does this have to do with Widgets?
>
> Glenn and I discussed this on IRC. Glenn suggested I add the following to
> the definition of a widget instance:
>
>  "The origin of a widget instance is the origin of the Document object
> associated with the widget instance's browsing context."
>
> I agree with Glenns recommendation, so I've go ahead and added that:
>
> http://dev.w3.org/2006/waf/widgets-api/#widget-instance


thanks Marcos, I drop my objection; regarding the reference to HTML5, it
would be an improvement if you could change section 6.5 from:

The concept of origin is defined in
[HTML]
.

to

The concept of origin of a Document object is defined in
[HTML]
.

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote:

> 
> 
> 
> On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:
> 
> > > in that case, please record an objection on my part 
> > 
> > 
> > just to be clear, I mean an objection to publishing as PR unless this is 
> > clarified; i believe this is an issue because the concept and use of origin 
> > is (1) very complex and (2) thus prone to misinterpretation; for example, 
> > it is not well recognized that HTML5 itself does not require a UA to send 
> > an Origin header in a URL request (see [3])
> Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web 
> Storage). But what does this have to do with Widgets? 

Glenn and I discussed this on IRC. Glenn suggested I add the following to the 
definition of a widget instance:

 "The origin of a widget instance is the origin of the Document object 
associated with the widget instance's browsing context."

I agree with Glenns recommendation, so I've go ahead and added that:

http://dev.w3.org/2006/waf/widgets-api/#widget-instance


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:

> > in that case, please record an objection on my part 
> 
> 
> just to be clear, I mean an objection to publishing as PR unless this is 
> clarified; i believe this is an issue because the concept and use of origin 
> is (1) very complex and (2) thus prone to misinterpretation; for example, it 
> is not well recognized that HTML5 itself does not require a UA to send an 
> Origin header in a URL request (see [3])
Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web 
Storage). But what does this have to do with Widgets? 

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:04 AM, Glenn Adams  wrote:

>
> On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres 
> wrote:
>
>> On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
>>
>> >
>> > On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres <
>> marcosscace...@gmail.com (mailto:marcosscace...@gmail.com)> wrote:
>> > > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
>> > > > Marcos - would you please enumerate the CR's uses of HTML5 and state
>> > > > whether each usage is to a stable part of HTML5?
>> > >
>> > > 3. "When getting or setting the preferences attribute, if the origin
>> of a widget instance is mutable (e.g., if the user agent allows
>> document.domain to be dynamically changed), then the user agent must
>> perform the preference-origin security check. The concept of origin is
>> defined in [HTML]."
>> > > Origin is concept that is well understood - as is the same origin
>> policy used by browsers.
>> >
>> >
>> > TWI [1] does not define "the origin of a widget instance".
>> That's because they are not bound to any particular URI scheme. Just to
>> some origin.
>> > Nor does HTML5. It is also confusing to say that HTML5 defines the
>> 'concept of origin', given that it normatively refers to The Web Origin
>> Concept [2]. TWI needs to be more specific about what aspect of Origin is
>> being referenced and where that specific aspect is defined.
>>
>> As there are no interoperability issues, I don't agree the TWI spec needs
>> to be updated any further. It's just a simple spec and any further
>> clarifications would just be academic.
>> >
>> > [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
>> > [2] http://tools.ietf.org/html/rfc6454
>>
>
> in that case, please record an objection on my part
>

just to be clear, I mean an objection to publishing as PR unless this is
clarified; i believe this is an issue because the concept and use of origin
is (1) very complex and (2) thus prone to misinterpretation; for example,
it is not well recognized that HTML5 itself does not require a UA to send
an Origin header in a URL request (see [3])

[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 16:04, Glenn Adams wrote:

> 
> On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres  (mailto:marcosscace...@gmail.com)> wrote:
> > On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
> > 
> > > 
> > > On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres  > > (mailto:marcosscace...@gmail.com) (mailto:marcosscace...@gmail.com)> 
> > > wrote:
> > > > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > > > > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > > > > whether each usage is to a stable part of HTML5?
> > > > 
> > > > 
> > > > 3. "When getting or setting the preferences attribute, if the origin of 
> > > > a widget instance is mutable (e.g., if the user agent allows 
> > > > document.domain to be dynamically changed), then the user agent must 
> > > > perform the preference-origin security check. The concept of origin is 
> > > > defined in [HTML]."
> > > > Origin is concept that is well understood - as is the same origin 
> > > > policy used by browsers.
> > > 
> > > 
> > > 
> > > TWI [1] does not define "the origin of a widget instance".
> > That's because they are not bound to any particular URI scheme. Just to 
> > some origin.
> > > Nor does HTML5. It is also confusing to say that HTML5 defines the 
> > > 'concept of origin', given that it normatively refers to The Web Origin 
> > > Concept [2]. TWI needs to be more specific about what aspect of Origin is 
> > > being referenced and where that specific aspect is defined.
> > 
> > 
> > As there are no interoperability issues, I don't agree the TWI spec needs 
> > to be updated any further. It's just a simple spec and any further 
> > clarifications would just be academic.
> > > 
> > > [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
> > > [2] http://tools.ietf.org/html/rfc6454
> > 
> 
> 
> in that case, please record an objection on my part
> 

What, exactly, are you objecting to? Can you demonstrate that there is an 
issue?  

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres wrote:

> On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
>
> >
> > On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres <
> marcosscace...@gmail.com (mailto:marcosscace...@gmail.com)> wrote:
> > > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > > > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > > > whether each usage is to a stable part of HTML5?
> > >
> > > 3. "When getting or setting the preferences attribute, if the origin
> of a widget instance is mutable (e.g., if the user agent allows
> document.domain to be dynamically changed), then the user agent must
> perform the preference-origin security check. The concept of origin is
> defined in [HTML]."
> > > Origin is concept that is well understood - as is the same origin
> policy used by browsers.
> >
> >
> > TWI [1] does not define "the origin of a widget instance".
> That's because they are not bound to any particular URI scheme. Just to
> some origin.
> > Nor does HTML5. It is also confusing to say that HTML5 defines the
> 'concept of origin', given that it normatively refers to The Web Origin
> Concept [2]. TWI needs to be more specific about what aspect of Origin is
> being referenced and where that specific aspect is defined.
>
> As there are no interoperability issues, I don't agree the TWI spec needs
> to be updated any further. It's just a simple spec and any further
> clarifications would just be academic.
> >
> > [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
> > [2] http://tools.ietf.org/html/rfc6454
>

in that case, please record an objection on my part

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:

> 
> On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres  (mailto:marcosscace...@gmail.com)> wrote:
> > On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > > whether each usage is to a stable part of HTML5?
> > 
> > 3. "When getting or setting the preferences attribute, if the origin of a 
> > widget instance is mutable (e.g., if the user agent allows document.domain 
> > to be dynamically changed), then the user agent must perform the 
> > preference-origin security check. The concept of origin is defined in 
> > [HTML]." 
> > Origin is concept that is well understood - as is the same origin policy 
> > used by browsers.
> 
> 
> TWI [1] does not define "the origin of a widget instance".
That's because they are not bound to any particular URI scheme. Just to some 
origin.  
> Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept 
> of origin', given that it normatively refers to The Web Origin Concept [2]. 
> TWI needs to be more specific about what aspect of Origin is being referenced 
> and where that specific aspect is defined.

As there are no interoperability issues, I don't agree the TWI spec needs to be 
updated any further. It's just a simple spec and any further clarifications 
would just be academic.   
> 
> [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
> [2] http://tools.ietf.org/html/rfc6454


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Glenn Adams]

On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres wrote:

> On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
> > Marcos - would you please enumerate the CR's uses of HTML5 and state
> > whether each usage is to a stable part of HTML5?
> 3. "When getting or setting the preferences attribute, if the origin of a
> widget instance is mutable (e.g., if the user agent allows document.domain
> to be dynamically changed), then the user agent must perform the
> preference-origin security check. The concept of origin is defined in
> [HTML]."
>
> Origin is concept that is well understood - as is the same origin policy
> used by browsers.
>

TWI [1] does not define "the origin of a widget instance". Nor does HTML5.
It is also confusing to say that HTML5 defines the 'concept of origin',
given that it normatively refers to The Web Origin Concept [2]. TWI needs
to be more specific about what aspect of Origin is being referenced and
where that specific aspect is defined.

[1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
[2] http://tools.ietf.org/html/rfc6454

CfC: publish Proposed Recommendation of Widget Interface; deadline April 26

[Arthur Barstow]

Now that the normative references for the Widget Interface spec have 
advanced and we have documented the spec only uses stable features of 
HTML5 [1], the Widget Interface is ready for publication as a Proposed 
Recommendation. As such, this is Call for Consensus to publish a PR of 
this spec using the following ED as the basis:




Note the Process Document includes the following regarding the entrance 
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented. 
Preferably, the Working Group SHOULD be able to demonstrate two 
interoperable implementations of each feature.

]]

As documented in this spec's CR [2], the CR exit criteria was met before 
the CR was published.


If you have any comments about this proposal, please send them to 
public-webapps@w3.org by April 26 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreeing with 
the proposal.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0246.html
[2] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 14:10, Arthur Barstow wrote:

> On 4/19/12 8:57 AM, ext Ian Jacobs wrote:
> > On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:
> >  
> > This is my expectation:
> > https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html
>  
>  
>  
> WebApps does all of its work in the Public. As such, would you or PLH  
> please forward that email to a Public list (preferably public-webapps)?

It says we can freely distribute the proposal to the group, so here it is:

Dear Chairs,

Documentation of our current practices for [0] for normative references
states:

   "In general, documents do not advance to Recommendation with
normative references to W3C specifications that are not yet
Recommendations."

However, several Working Groups have expressed a desire to reference
the HTML5 specification [1] even as a draft. The current expectation [2]
is that the HTML5 specification will become a Recommendation in 2014.

To address the needs of these groups sooner than 2014, we propose the
following for normative references to HTML5 (and only to HTML5) from
specifications scheduled to become Recommendations before HTML5.

Please, provide feedback and comments on this proposal until 22
September 2011 . Unless there are objections, we plan to implement this
proposal shortly thereafter. Feel free to circulate this proposal to your
Working Groups.  

Philippe Le Hégaret and Ian Jacobs

[0] http://www.w3.org/Guide/transitions
[1] http://www.w3.org/TR/html5/
[2] http://www.w3.org/2011/02/htmlwg-pr.html

=
Proposal for Normative References While HTML5 is not a Recommendation

* A Working Group X may propose normative references from a Proposed
  Recommendation or Recommendation to a set of definitions or
  implementable features in the HTML5 specification [1].

* Working Group X must indicate the presence of these references in any  
  Proposed [Edited] Recommendation or Recommendation transition request.

* The Director will evaluate these references and approve them when
satisfied that Working Group X has provided evidence that:

- The HTML Working Group has addressed all issues associated with the
  referenced HTML5 features or definitions, and that all issues have
  been resolved at least 60 days before the date of Working Group X's
  transition request.

- All referenced HTML5 features have been implemented.  Preferably,
  Working Group X should be able to demonstrate two interoperable
  implementations of each feature. If the Director believes that
  immediate Advisory Committee review is critical to the success of a
  technical report, the Director may accept normative references even
  without adequate HTML5 implementation experience.  

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Arthur Barstow]

On 4/19/12 8:57 AM, ext Ian Jacobs wrote:

On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:


Hi All,

As I understand it, the W3C's publication precedence re normative references 
for a Proposed Recommendation, is that all W3C normative references must be at 
CR or a later maturity level.

With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C normative 
reference in the Widget Interface Candidate Recommendation [TWI-CR] that is not 
at CR or later is HTML5.

Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 
are restricted to stable parts of the HTML5 spec, the Director will relax this 
publication precedence i.e. the Widget Interface may be published as a Proposed 
Recommendation. Is this correct?

This is my expectation:
  https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html


WebApps does all of its work in the Public. As such, would you or PLH 
please forward that email to a Public list (preferably public-webapps)?


-Thanks, AB

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Marcos Caceres]

On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:

> Marcos - would you please enumerate the CR's uses of HTML5 and state 
> whether each usage is to a stable part of HTML5?


1. "A browsing context that comes into existence after initialization. The 
concept of a browsing context is defined in [HTML]. Multiple widget instances 
can be instantiated from a single widget package. A widget instance is unique 
and does not share any DOM attribute values, widget storage area, or [Web 
Storage] storage areas with any other widget instance." 

Browsing context is a concept - and a well understood one at that. 

2. "User agent implementing [HTML]'s Window interface must implement the Widget 
interface as the widget attribute of the window object in the manner defined by 
the WindowWidget interface."

The window object is present in all browser implementations. Widgets to put any 
additional requirements on it.  

3. "When getting or setting the preferences attribute, if the origin of a 
widget instance is mutable (e.g., if the user agent allows document.domain to 
be dynamically changed), then the user agent must perform the preference-origin 
security check. The concept of origin is defined in [HTML]."   

Origin is concept that is well understood - as is the same origin policy used 
by browsers. 

Hope that helps! 

-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Ian Jacobs]

On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:

> Hi All,
> 
> As I understand it, the W3C's publication precedence re normative references 
> for a Proposed Recommendation, is that all W3C normative references must be 
> at CR or a later maturity level.
> 
> With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C 
> normative reference in the Widget Interface Candidate Recommendation [TWI-CR] 
> that is not at CR or later is HTML5.
> 
> Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 
> are restricted to stable parts of the HTML5 spec, the Director will relax 
> this publication precedence i.e. the Widget Interface may be published as a 
> Proposed Recommendation. Is this correct?

This is my expectation:
 https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html

Ian

> 
> Marcos - would you please enumerate the CR's uses of HTML5 and state whether 
> each usage is to a stable part of HTML5?
> 
> -Thanks, AB
> 
> [TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
> [WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/
> 
> 
> 

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

[widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

[Arthur Barstow]

Hi All,

As I understand it, the W3C's publication precedence re normative 
references for a Proposed Recommendation, is that all W3C normative 
references must be at CR or a later maturity level.


With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C 
normative reference in the Widget Interface Candidate Recommendation 
[TWI-CR] that is not at CR or later is HTML5.


Philippe, Ian - my understanding is that if the WG can show its uses of 
HTML5 are restricted to stable parts of the HTML5 spec, the Director 
will relax this publication precedence i.e. the Widget Interface may be 
published as a Proposed Recommendation. Is this correct?


Marcos - would you please enumerate the CR's uses of HTML5 and state 
whether each usage is to a stable part of HTML5?


-Thanks, AB

[TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
[WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/