- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Thu, 6 Sep 2007 14:15:08 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
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: public-webapi@w3.org > From: Ian Hickson <ian@hixie.ch> > Date: June 7, 2006 9:31:01 AM GMT+10:00 > To: public-webapi@w3.org > Subject: (XMLHttpRequest 2) Third proposal for cross-site > extensions to XMLHttpRequest > X-Archived-At: http://www.w3.org/mid/Pine.LNX. > 4.62.0606062320020.10674@dhalsim.dreamhost.com > > > > 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 mnot@yahoo-inc.com
Received on Thursday, 6 September 2007 04:16:38 UTC