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
