Re: [XHR2] AnonXMLHttpRequest()

On Tue, Feb 2, 2010 at 11:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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?

Perhaps the best way to fix this is to have the definition of the
credentials flag reference UMP.

I think it's worth noting that Adam Barth's review of UMP went into
significant detail on the definition of credentials, but I don't
recall him raising similar points about CORS, though they would
obviously apply. I take this as further evidence that having separate
specifications improves clarity.

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

CORS must not claim that its requests-with-credentials are uniform
requests. That would be incorrect and a violation of the UMP spec.
Instead, CORS could define its requests as
uniform-requests-plus-credentials and give this new construct a new
name. In programmer speak, CORS could extend UMP using composition
rather than inheritance.

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

If it's not possible to coax an existing implementation into sending
"Origin: null", then, in the extreme, it's possible to create a newly
generated domain name and send the request from there, so that the
Origin header has a value to which no semantics are attached.

Again, I'm *not* arguing that existing CORS implementations provide a
clean and usable interface for using UMP. They clearly don't. I'm only
arguing that UMP defines functionality that existing implementations
have implicitly agreed to support, since they support sending of
semantically equivalent messages (there was never any guarantee that
the Origin header contained information that was meaningful to the
server). As you pointed out, there's still the issue of redirect
handling, but AFAICT, CORS implementations are not perfectly aligned
here either.

We should open a new thread on the redirect question, as there are
clearly issues that remain to be solved both within CORS itself and
between CORS and UMP. I'd also like the opportunity to convince the WG
that the UMP handling of redirects is the technically superior choice.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 3 February 2010 17:58:31 UTC