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

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 June 2006 23:31:13 UTC