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

Hi Mark,

First a couple of corrections...

On Feb 3, 2010, at 5:31 PM, Mark S. Miller wrote:

> Hi Maciej and Tyler, 
> 
> IMO, the important subsetting points, in priority order, are:
> 
> 1) Server-side behavior compatible with UMP is automatically compatible with CORS and with present CORS-like browser behaviors.
> 2) The client-side mechanisms one needs to implement UMP correctly are a small subset of the mechanisms one needs to implement CORS. Having made the investment in implementing CORS-like mechanisms, no significant further internal mechanism is needed to implement UMP. (Indeed, I wouldn't be surprised if one could derive an UMP implementation from a CORS implementation mostly by commenting out code.)

That's unlikely. To implement UMP, we would have to write code to remove or specifically avoid things that we'd otherwise put in every request. (Beyond that, we'd also want to share code with CORS, so having something that's defined as a CORS subset or mode would make it easy to know where to put the if statements.)

> 3) Given other proposals already on the table -- CORS and unique-origin iframes -- one could build the proposed xhr-like UniformRequest API as a library on top. Though these requests would include an unneeded "Origin: null" header, such a header is not a credential and so would not violate any MUST in UMP. The messages would still be Uniform.

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.

> 
> I think this thread has focussed exclusively on point #3 and lost sight of points #1 and #2.

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. 
(B) Every Uniform Response should also be a valid CORS response.
(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.

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. 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. I am not currently aware of any violations of (B).

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:

(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.

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.

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.

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.

Regards,
Maciej

Received on Thursday, 4 February 2010 03:40:56 UTC