On Apr 8, 2010, at 5:20 PM, Tyler Close wrote:
On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak <[email protected]>
wrote:
Actually, the other proposal is to provide an XHR-like API that
would use CORS forcing a unique origin as an input parameter -
there is no need to
My hope is that this would be semantically equivalent to using UMP.
This unique origin would still need to discard Set-Cookie response
headers to prevent the accumulation of credentials associated with the
unique origin. It would also need to prohibit the reuse of a TLS
client authenticated connection or NTLM authenticated connection. It
would also need to prevent use of cache entries populated by
non-uniform requests. The CORS draft is also unclear on what happens
with the Referer header.
Good point. It seems like these should all be raised as issues on
CORS. I will do it if you don't beat me.
What I'm looking for is a clear and objective way to evaluate the
desired subset properties. Here are some clear-cut subset
properties that I think will give most of the interoperability and
ease of implementation you want:
(A) Every Uniform Request should also be a valid CORS request.
.
...with the same semantics. The goals being:
1) an UMP API can safely and successfully send a uniform request to a
CORS resource
2) a CORS API can safely send a request to an UMP resource, which may
choose to either fail or allow the request
Sounds good, although I meant this to only be a syntactic criterion -
(C) is intended to be the semantic / processing requirements criterion.
(B) Every Uniform Response should also be a valid CORS response.
...with the same semantics. The goal being:
1) an UMP resource can safely and successfully return a uniform
response to a CORS API
2) a CORS resource can safely and successfully return a uniform
response to an UMP API
Given the above, a developer can read only UMP and ignore CORS and
still write safe code that works. That's what I mean by "subset".
Also agree to your clarifications.
(C) When a CORS client makes a Uniform Request and receives either
a Uniform Response, or an HTTP response that is neither a Uniform
Response nor a response would allow access under CORS rules, then
the processing requirements under CORS are the same as the
processing requirements under UMP.
(C) seems the same as (B) if we assume both CORS and UMP properly
reject Same-Origin-only responses.
I'd like to have a rule explicitly about the processing requirements
rather than have that implied by rules about semantics. "Semantics" is
not quite clear-cut enough to evaluate objectively.
Currently (A) and (C) do not hold. One counter-example to (A): a
request that contains no Origin header at all, not even Origin:
null, may be a Uniform Request but is not a valid CORS request.
I think it would be safe for a CORS resource to assume Origin: null
when no Origin is provided. I agree the current spec doesn't say so.
Either UMP or CORS could change here, but we have to agree which to
change and do it. I don't actually know if assuming "Origin: null" in
the absence of an origin is safe; that's a change to the model that
would have to be reviewed. I am pretty confident that adding "Origin:
null" to a Uniform Request does not pose a security risk, though it
may be seen as unnecessary from the UMP-only perspective. I also do
not know if this is the only counter-example; I did not do a thorough
review UMP and CORS against these criteria at the time. I think we
should review carefully according to these criteria and reconcile all
violations before either spec goes to CR (and ideally before either
goes to LC).
One counter-example to (C): UMP will follow a redirect that is
neither a Uniform Response nor allows access under CORS; but CORS
will not.
This has since been reconciled.
Good news.
I am not currently aware of any violations of (B).
(B)(2) is currently violated by the difference in response header
filtering. This can be reconciled when the current open CORS issue
about response headers is closed. It'll be interesting to see how this
issue is resolved since it is potentially very contentious. Banning
response headers seriously affects the extensibility of HTTP.
Can you explain more specifically what the (B) violation is?
Also, the reason the conditions on (C) are a little funny: I think
it's possible that a CORS implementation could make a Uniform
Request that receives a non-Uniform Response that nontheless allows
access, but I'm actually not sure if this is possible. It's
definitely possible if it is legal to send multiple "Access-Control-
Allow-Origin:" headers in a response, or to send "Access-Control-
Allow-Origin: null". I am not sure if either of these is allowed.
I'm also not sure if there are other possible CORS responses that
would violate the Uniform Request requirements or UMP processing
model. If there are no such conflicts, then we could tighten C to:
An UMP resource is only allowed to respond with a single
Access-Control-Allow-Origin: *. Other values are undefined by UMP and
so don't offer any defined behavior that an UMP resource can rely
upon. That's not a violation of (C) through, since (C) says the
response is either a uniform response or one rejected by both UMP and
CORS.
(C') When a CORS client makes a Uniform Request and receives any
response, then the processing requirements under CORS are the same
as the processing requirements under UMP.
CORS defines more kinds of successful responses than does UMP, since
it supports additional values for the Access-Control-Allow-Origin
header. So (C') would be violated if a non-compliant UMP resource
responded with an Access-Control-Allow-Origin header with a value
matching the received Origin header.
I am ok with not having (C') as one of the criteria.
Also none of this squarely addresses your original point 1: whether
a UMP server would automatically be compatible with a CORS request
that is *not* a Uniform Request. That would require a condition
something like this:
(D) When a UMP server receives a CORS Request that is not a Uniform
Request, if it would have granted access to the same request with
all user and server credentials removed, it must process the CORS
request in the same way as it would if all credentials had in fact
been omitted.
I don't think (D) follows from the current requirements, and I'm
not entirely sure if it is practical to enforce through requirements.
...or desirable. I can imagine a resource that legitimately wanted to
reject all non-uniform requests. For example, there may be a back-end
that doesn't trust its front-end to ignore credentials, so it fails
all non-uniform requests so that such requests trigger test failures
that can be detected.
I agree; I do not think (D) is a useful property to ensure.
Whether CORS and UMP satisfy the various subset relations described
here is something that can be determined objectively through review
of both drafts. Relation conditions like "small subset of the
mechanisms" or "automatically compatible" are harder to pin down. I
would like to ensure that CORS and UMP satisfy at least relations
(A), (B) and (C), and if desirable and practical, also (C') and
(D). Note: I'm not making any assumptions here about which of CORS
or UMP should change to address any given violation of the subset
relation.
I think (A) and (B) define the subset relationship we should aim for.
I would prefer to still include (C) to the extent that it require
anything additional on top of (A) and (B).
If we satisfy all of these relations, then once we have an API that
allows making requests that satisfy the Uniform Request
requirements via CORS, it will be usable as a UMP API as well.
Sure. Whether or not it is desirable to have both living under the
same API is still a question though.
Definitely a valid question, but separate from the subset relation, I
think.
Regards,
Maciej
