On Tue, Feb 2, 2010 at 5:14 PM, Maciej Stachowiak <m...@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 <m...@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? > > Since we've all noted that CORS and UMP take a different approach to > > the problem, I think it would be confusing to bundle them in a single > > spec. If CORS wants to be a superset of UMP, then I think it's best to > > write CORS as an extension of UMP, and so referencing UMP, rather than > > absorbing it. This specification layout would also make it easier to > > communicate the differences between an AnonXMLHttpRequest (or > > UniformRequest) and an XHR2; each would link to their corresponding > > spec document without needing to select only the relevant > > sub-sections. > > CORS algorithms are parameterized, so API specs don't have to link to a > specific section, just define the input parameters. This is far more confusing that just linking to the corresponding spec. There's too much extra information that only serves to confuse. The UMP spec will be consumed not just by API spec writers, but also by Web application developers. > 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. > > Since UMP is also much smaller and simpler than CORS, I think it makes > > sense to push it through the standardization process at a faster pace > > than CORS. For example, I think it is reasonable to move UMP to Last > > Call as early as next month, or the even the end of this month. > > I'm not sure this makes sense if we want to maintain the subset relation. I don't follow, why does maintaining the subset relation preclude Last Call for UMP? It seems quite unfair for the maturity of the UMP specification to be held hostage by the CORS specification when UMP has no dependency on CORS. > 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. 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. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html