* Start with the current functionality of XDomainRequest
* Rename it to something suitably vendor-neutral (DataRequest)
* Keep the same basic handshaking approach from XDR where servers reject
requests that don't have a DataRequest header and the browser rejects
responses that don't have a DataRequestAllowed header
* Add support for all of the same HTTP methods as in AC (i.e., not just
GET and POST)
* Like AC and JSONRequest, the request includes the originating domain
that is making the cross-site request. (MS is likely to have heartburn
over this one because XDR doesn't send the domain for privacy reasons,
but maybe this can be a browser security preference where some browsers
can set a default of don't-send-originating-domain)
* Like XDomainRequest, there is a preflight check on all requests, but
the preflight check follows the approach used in AC, where
MyDataRequest.open(method, url) uses an OPTIONS request/response in the
background for the pre-flight check
* The OPTIONS request returns not only a DataRequestAllowed:1 header
(per XDR) to indicate whether the given method is supported, but in some
cases returns other headers that help with security, such as a Max-Age
header (per AC)
* Define another OPTIONS response header to allow a server to opt-in to
transmission of cookies
* Decide whether the random delay feature from JSONRequest is a good idea
* NOTE: the resulting technology does not include client-side allow/deny
processing
* NOTE: the spec should SHOUT about vulnerability risks if certain
features are turned on (such as allowing POST/PUT/DELETE or transmission
of cookies) and about how the server should not trust what is in the
request (such as the originating domain)
It seems to me like with all these changes you rather end up with
something much more similar to AC than XDR. With differently named
headers (which of course matters very little).
Also, isn't doing the OPTIONS request moving the PEP into the client ;)
/ Jonas
