On Feb 3, 2010, at 9:57 AM, Tyler Close wrote: > On Tue, Feb 2, 2010 at 11:37 PM, Maciej Stachowiak <m...@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.
If there were separate clear definitions of user credentials and site credentials, then it would be reasonable to find some way to share them. (The CORS credentials flag is only meant to exclude user credentials. But when it ends up sending a null origin, it should also exclude site credentials. So it needs two definitions.) > > 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. Valid CORS requests can (and in some cases MUST) include everything that is forbidden for Uniform Requests. Trying to define a CORS request in terms of a Uniform Request would likely involve stating that none of the restrictions of a Uniform Request relative to a general HTTP request apply, but instead some other restrictions apply. That doesn't seem to gain anything over defining CORS requests as a subset of HTTP requests, if anything it would be more awkward. If Uniform Requests were defined by what they *do* include then it might be more convenient to define CORS requests in terms of them. > >> 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. It's certainly possible to create a domain on the fly as a subdomain of a domain you control. I don't think it is possible to make a new domain every time that would be a direct subdomain of a TLD. So there's really no way to make the origin carry no information. You could ensure the information is in an inconvenient form, but I don't think you can omit it entirely. > > 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). I would say existing implementations not only fail to provide a clean and usable interface but that they fail to provide any interface for using UMP. > 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. Agreed. When I asked Anne, he said the right way to track issues with CORS was to use the Web Apps WG Issue Tracker: <http://www.w3.org/2008/webapps/track/>. Is that ok by you too for UMP issues? If so, I'll raise an issue to resolve the discrepancy. Regards, Maciej
