Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

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