- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 08 Apr 2010 17:51:16 -0700
- To: Tyler Close <tyler.close@gmail.com>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Apr 8, 2010, at 5:20 PM, Tyler Close wrote: > On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak <mjs@apple.com> > 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
Received on Friday, 9 April 2010 00:51:50 UTC