Re: UMP / CORS: Implementor Interest

Maciej Stachowiak 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.
> 
> (Regarding the proposal you quoted, I don't understand how the new header is materially different from CORS/UMP, which are both use opt-in response headers that allow cross-origin access.)

The original issue is that CORS doesn't as yet allow for opt-in headers, 
Maciej Stachowiak earlier suggested (amongst renaming all the other 
headers):

   new header to expose more response headers ==> Expose-Headers (or 
Expose-Response-Headers)

UMP does cater for this.

The specific issue I need to get around (as an app developer and not a 
vendor) - note: not spam, clarifying to save you good busy people from 
trawling this huge thread - is:

I've (amongst others) have adopted a new Web Access Control & SSL auth* 
model, and under this model HTTPS conflicts with the same origin rules 
for XHR.

I spoke to TimBL about it, who said to adopt CORS, but under closer 
inspection I've found the headers needed for the model he proposes (and 
for REST) are not allowed in the current draft of CORS. Namely Link and 
Location.

Whilst the above quoted is overkill, the (now over mentioned by me) 
Expose-Headers suggestion from Maciej Stachowiak or UMPs Uniform-Headers 
would both solve the problem :)

Regardless of the UMP/CORS thing, I (along with most of the people doing 
Read-Write-Web / Linked Data / FOAF+SSL / REST) would value a header 
opt-in solution being in both drafts; that is, it's critical to the web 
of data & UK/US Government Linked Data efforts moving forwards.

Best,

Nathan

Received on Thursday, 13 May 2010 12:01:00 UTC