Subject: Fwd: (XMLHttpRequest 2) Third proposal for cross-site extensions to XMLHttpRequest

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Sep 2007 14:15:08 +1000

AFAICT this hasn't been discussed here.

In a nutshell, the purpose is to allow browsers to send scripted  
requests (e.g., JavaScript XmlHttpRequest) to sites other than that  
which generated the content it resides in; i.e., a "cross-site" request.

Note the definition of new headers, as well as the "security check"  
request preceding non-GET/POST methods (recent discussion indicates  
this may be pared down to just GET).

See also <http://www.w3.org/TR/access-control/>.

It's starting to get implementation, so if you want to give feedback,  
do so soon (on the webapi list).

Begin forwarded message:

> Resent-From: [email-masked]
> From: Ian Hickson <[email-masked]>
> Date: June 7, 2006 9:31:01 AM GMT+10:00
> To: [email-masked]
> Subject: (XMLHttpRequest 2) Third proposal for cross-site  
> extensions to  XMLHttpRequest
> X-Archived-At: http://www.w3.org/mid/Pine.LNX. 
> [email-masked]
>
>
>
> Updated proposal for cross-site extensions to XMLHttpRequest, based on
> implementation feedback:
>
> In all cases:
>
>    setRequestHeader() must be prevented from setting the Referer,
>    Referer-Root, Content-Access-Control, and XMLHttpRequest-Security-
>    Check headers, in addition to any normal restrictions.
>
> If the open() method is called with a URI that points to a third-party
> domain, or if the method is called with a URI to the first-party host
> but that is then redirected to a third-party domain, then:
>
>    send() must include a Referer-Root header that consists of the
>    scheme, hostname and port portions of the original domain of the
>    global scope of the script originating the request in every request
>    in causes to be sent to a third-party host, as follows. The scheme
>    must be given first, in canonical case, followed by a U+003A
>    COLON. If the scheme supports hosts and ports then the colon must
>    be followed by two U+002F SOLIDUS characters followed by the
>    canonical punycode representation of the host name, or, if the host
>    is an IP address, its canonical representation (for IPv4, the
>    dotted quad form; for IPv6, the second text representation given in
>    RFC2373, surrounded by square brackets as per RFC 2732). If the
>    port is not the standard port for the given scheme, then the host
>    name must be followed by a U+003A COLON and the port number.
>
>    If the method is GET, then the send() method must fetch the
>    resource indicated by the URI, with no payload, then must perform
>    an access check (see below), and if that is positive, it must make
>    the document available (see below). If the check is negative, it
>    must act as if there was a network-level failure.
>
>    If the method is POST, then the send() method must perform the
>    submission to the resource indicated by the URI, with the payload,
>    then must perform an access check (see below), and if that is
>    positive, it must make the document available (see below). If the
>    check is negative, it must act as if there was a network-level
>    failure.
>
>    If the method is not GET or POST, then the send() method must make
>    a GET request to the third-party host at the given URI, without any
>    payload, and with an additional header, XMLHttpRequest-Security-
>    Check, whose value is the requested method. If the request, after
>    following any redirects, is successful, the user agent must perform
>    an access check on the returned document (see below). If the check
>    is positive, AND if the check contains an Allow header that
>    mentions the method that the UA wants to attempt, then the UA must
>    send the actual request (with the correct method and complete
>    payload), perform an access check on _that_ document (see below),
>    and if it is again positive, must make the return document
>    available (see below). If the actual request is redirected in a way
>    that differs from the way the original (GET) security request was
>    redirected, then the redirect must not be honored. Similarly, if a
>    non-GET and non-POST request is made to the first-party host which
>    subsequently redirects to a third-party host, the redirect must not
>    be honored. If either document fails the access check, or if one of
>    the redirects is not honored, then the user agent must act as if
>    there had been a network-level failure.
>
>    Note: The initial request should be cached to the extent allowed by
>    its response headers, so that subsequent non-GET and non-POST
>    requests can use the cached response instead of having to hit the
>    network twice for every request.
>
>
>    Access check: If there are response headers with the name
>    "Content-Access-Control", then they must have their values parsed
>    as the data part of an <?access-control?> PI.
>
>    In addition, if the document has an XML MIME type, then the
>    document must be further processed according to the Access Control
>    specification.
>
>    In either case, if, according to the processing model in the Access
>    Control specification, the headers (if any) and/or PIs (if any)
>    indicate that the originating site is allowed to access the
>    document, then the access check is positive, otherwise it is
>    negative (failed check).
>
>    Note: The Access Contcol specification defines how multiple PIs (or
>    headers, since they are just treated like PIs) are to be handled.
>
>    Redirects must be followed before checking for security headers.
>
>
>    Making the document available: if the access check for the document
>    is positive, then the various responseXXXX headers must be  
> initialised
>    appropriately. The security context of the document must be the  
> same as
>    that of the originating site. The getAllResponseHeaders() method  
> must
>    return the empty string, and the getResponseHeader() method must  
> not
>    return any header values except for the following headers:
>    Cache-Control, Content-Language, Content-Type, Expires, Last- 
> Modified,
>    Pragma. The document.cookie attribute must return the empty string,
>    and must do nothing when set.
>
>
> Acknowldegements:
>
>    Thanks to Darin Fisher.
>
>
> PS. I have decided that the Cross-site Extensions to XMLHttpRequest
> specification should have the acronym XXX. I figure if I'm going to be
> involved in a spec that has an X in the name, I'd better go the  
> whole way.
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>
>

--
Mark Nottingham       [email-masked]

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 06 Sep 2007 12:34:17 +0200

On Thu, 06 Sep 2007 06:15:08 +0200, Mark Nottingham <[email-masked]>  
wrote:
> request preceding non-GET/POST methods (recent discussion indicates this  
> may be pared down to just GET).
>

The proposal from Ian Hickson has been incorperated in a draft for  
XMLHttpRequest level 2. It probably makes more sense to review that:

   http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html
   http://dev.w3.org/2006/waf/access-control/Overview.html

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Sep 2007 22:01:58 +1000

Ah, thanks; I missed that.

See also:
<http://wiki.mozilla.org/Cross_Site_XMLHttpRequest>

On 2007/09/06, at 8:34 PM, Anne van Kesteren wrote:

> On Thu, 06 Sep 2007 06:15:08 +0200, Mark Nottingham <mnot@yahoo- 
> inc.com> wrote:
>> requests (e.g., JavaScript XmlHttpRequest) to sites other than  
>> that which generated the content it resides in; i.e., a "cross- 
>> site" request.
>>
>> Note the definition of new headers, as well as the "security  
>> check" request preceding non-GET/POST methods (recent discussion  
>> indicates this may be pared down to just GET).
>>