Re: [XHR2] AnonXMLHttpRequest()

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?

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

Received on Wednesday, 3 February 2010 05:43:22 UTC