W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: UMP / CORS: Implementor Interest

From: Tyler Close <tyler.close@gmail.com>
Date: Thu, 13 May 2010 09:24:14 -0700
Message-ID: <AANLkTil9DfTobFgwDcXxad-PGvTp-X56N8_ebgaVb8-r@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, nathan@webr3.org, Devdatta <dev.akhawe@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Arthur Barstow <Art.Barstow@nokia.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
On Thu, May 13, 2010 at 3:48 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On May 13, 2010, at 3:05 AM, Julian Reschke wrote:
>
>> On 12.05.2010 22:39, Nathan wrote:
>>> Devdatta wrote:
>>>>> As for the "should CORS exist" discussion, I'll bow out of those until
>>>>> we're starting to move towards officially adopting a WG decision one
>>>>> way or another, or genuinely new information is provided which would
>>>>> affect such a decision (for the record, I don't think I've seen any
>>>>> new information provided since last fall's TPAC).
>>>>
>>>> exactly -- I don't see this thread getting anywhere.
>>>
>>> Vendors & Spec writers,
>>>
>>> What would be really nice is if you gave us server admins, application
>>> server-side developers and data publishers a say in this.
>>>
>>> Thus I'll propose a new header:
>>>
>>> Allow-XHR = "Allow-XHR" ":" Allow-XHR-v
>>> Allow-XHR-v = "none" | "negotiate" | "all"
>>>
>>> "none" defines no XHR access
>>>
>>> "negotiate" defines the UA should negotiate CORS or UMP headers (leave
>>> that up to you guys to decide what's best ;)
>>>
>>> "all" defines that the UA should process the XHR request as a normal
>>> client HTTP request leaving all information + headers intact.
>>> ...
>>
>> From the side line: I hear that people were worried about having to add new response headers just for CORS & friends. Was it ever discussed to send these response headers only based on something in the *request*?
>
> That's already how CORS works, essentially. You don't need to send the Access-Control-Allow-Origin header or other headers, unless you see a request with a non-same origin Origin header. The no-credentials subset of CORS is a bit weaker. It sends "Origin: null", which could also be triggered by something like traversing a link. UMP doesn't provide for this at all - there is no required header in a UMP request that can distinguish it from any other request.

The presence or absence of a Cookie header could be used for this
micro optimization in UMP: no Cookie, include the
Access-Control-Allow-Origin header; otherwise don't.

--Tyler


-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Thursday, 13 May 2010 18:07:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT