Re: [XHR2] AnonXMLHttpRequest()

On Feb 2, 2010, at 9:42 PM, Tyler Close wrote:

> On Tue, Feb 2, 2010 at 5:14 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> 
>> On Feb 2, 2010, at 11:15 AM, Tyler Close wrote:
>> 
>>> On Sun, Jan 31, 2010 at 11:03 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>> I'm curious what practical differences there are between CORS with the credentials flag
>>>> set to false and the origin set to "null", and UMP. Are there any?
>>> 
>>> The credentials flag in CORS is underspecified, so it's hard to answer
>>> this question.
>> 
>> Can you be more specific? What is underspecified about it? Sounds like something we should fix.
> 
> Nowhere does CORS define what a credential is. Nowhere does it list
> specific credentials a browser may have but should not use when the
> credential flag is false. Does CORS treat the Origin header as a
> credential? What other identifiers are not credentials? What about
> proxy credentials?

Fair point. It looks like the only actual statement about the effect of the credentials flag is:

"Whenever the make a request steps are applied, make a request to request URL, using method request method, entity body request entity body, including the custom request headers, and include credentials if the credentials flag is true (e.g. HTTP authentication data and cookies)."

There's two problems with this:

(1) It's not normatively defined what constitutes a credential.
(2) It says to include credentials when the credentials flag is true, but it doesn't say they must not be included when the credentials flag is false.

I think the credentials flag should specifically affect cookies, http authentication, and client-side SSL certs, but not proxy authentication (or, obviously, Origin). Anne, can you fix this?

> 
>> Does UMP have extension hooks sufficient to allow CORS to be written as a UMP extension as you suggest?
> 
> UMP has a declarative specification. You extend UMP the same way you
> extend other HTTP-based protocols, by defining new protocol tokens and
> attaching semantics to them. For example, CORS would define new
> semantics for new values of the Access-Control-Allow-Origin header.

A CORS message would clearly not satisfy the declarative definition of "a Uniform Request". Since this definition is based partly on what MUST NOT be included, I don't see any way to extend it. 

> 
>> And if we don't want to maintain the subset relation, then I would oppose advancing UMP at all.
>> 
>>> 
>>>> Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send "Origin: null" instead of the sender's actual Origin.
>>> 
>>> As the UMP spec notes, it is within the intersection of what has been
>>> commonly deployed across user-agents. I'm curious to learn Microsoft's
>>> assessment of UMP, since, as you note, it is very close to their own
>>> XDomainRequest.
>> 
>> Actually, it's not within the intersection, since it requires "Origin: null" rather than the actual Origin. No user agent currently has an API that generates UMP-conformant requests.
> 
> As you said above, there is a subset relation between CORS and UMP,
> which puts UMP in the intersection of existing CORS implementations.

No existing CORS implementation will satisfy the requirements for a Uniform Request, as far as I can tell, since it includes "information obtained from... the referring resource, including its origin". It is possible to send a request satisfying the "Uniform Request" requirements by passing the right parameters to CORS (a "unique identifier" origin would result in "Origin: null" being sent), so the subset relation exists at the protocol level. But I don't think any implementation will end up passing the right parameters to CRS, so the intersection of the subsets of CORS supported by existing implementations does not overlap the UMP subset of CORS.

(I note also that the definition of "Uniform Request" includes some messages that could not be produced by CORS at all. For example it seems like it would be valid to send no Origin header at all, instead of "Origin: null". This arguably violates the subset relation. It also allows a Uniform Request to look just like a same-origin XHR request from a legacy UA, which is not possible with CORS. Not sure if that is in itself a problem.

This is in addition to the previously identified violation of the subset relation in redirect handling. where CORS will allow the client to read the results of following a redirect in some cases where CORS will not.

Can we use some kind of bug tracker to track these issues?)

> With some awkward messing around with iframes and such, I think the
> existing implementations can be made to put a non-meaningful
> identifier in the Origin header. Not a situation I'd want to work with
> going forward, but good enough to claim the intersection.

I don't see how? Making an XDR or XHR2 request will always send an Origin. Using an <iframe> and postMessage (or similar technique) you could get them to send a different Origin than the containing page's, but if that origin is controlled by the same entity as the client's domain then it is still an identifier, and if it is a single shared domain controlled by the service, not the client, then we're really using a client-side postMessage-based <iframe> API as the interface to the service, not UMP. (Note that postMessage itself carries an Origin so it would not have the claimed UMP benefit of not identifying the requesting Origin.) Maybe you have something else in mind.

Regards,
Maciej