[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

Thu Mar 10 00:24:59 PST 2005

Also,

Somebody had mentioned that we could just extend the existing
XmlHttpRequest object. Here's why I'm leaning toward creating a new
object, and why I named it "ContextAgnosticXmlHttpRequest":

When requesting a different host, we don't want the user agent to be
sending along cookies pertaining to that domain. Same goes for any
cached HTTP Basic Auth credentials. I'm not sure we want to silently
disable these features without making it clear to developers that "HEY
guys, you're dealing with an entirely different beast here", so the
only way a web document is ever allowed to retrieve XML data over HTTP
from a host that is different from the one that served it, is if these
two conditions are met:

1) the service you're calling is explicitly granting you access
2) under no circumstance can any "stored" personal user information
ever be sent as part of the request. "ContextAgnostic" in this case
means this new "flavor" of the  XmlHttpRequest has no insight into the
results of past HTTP transactions that may have occurred with this
foreign host, within the context of an actual web browsing session.

The thread i'm replying to right now is mainly addressing 1)
My original blog entry (
http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
)  was mainly addressing 2)

-chris

On Thu, 10 Mar 2005 00:01:00 -0800, Chris Holland <frenchy at gmail.com> wrote:
> It's an interesting document:
> 
> "SOAP messages have a distinct processing model allowing a header to
> be added that the recipient is required to understand and accept,
> which identifies the untrusted source of a script making a request.
> SOAP services which have not been cleared for access by untrusted
> scripts will reject the requests.  This is offered in the Mozilla
> implementation of SOAP today."
> 
> which kinda sounds like what we're headed to with an
> "X-Allow-Foreign-Host" header sent by the service. Except that the
> implementation they're offering would offer crazy granularity in
> access control. I'm not sure that in the specific case of HTTP/XML
> requests we'd want to add this much overhead in the handshaking,
> though the idea is still good.
> 
> To reduce overhead, I do like Hallvord's suggestion of an HTTP HEAD
> request *first*. Let's look at a sample flow:
> 
> 1) user lands on http://www.domainA.com/documentA.html
> 
> 2) scripting logic in documentA.html is attempting to make an
> XmlHttpRequest to http://www.domainB.com/restfulservice/someobject
>     a) ooops, the HOST is different, let's see whether I'm allowed to call it:
>     b) Request:
>            HEAD /restfulservice/someobject HTTP/1.1
>            ... [headers TBD] (initial thoughts over here:
> http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
> )
> 
>     c) Response:
>           traditional response headers plus the following header:
>           X-Allow-Foreign-Documents-From-Hosts: All | *.domainB.com
> 
>     d) "cool" i'm allowed to call this service from the current web document:
>          follow the HEAD request with one or more subsequent GET requests.
> 
> the b) + c) roundtrip could be handled in an equivalent to what the
> lxr.mozilla.org spec (
> http://lxr.mozilla.org/seamonkey/source/extensions/webservices/docs/New_Security_Model.html
> ) referred to as the nsWebScriptsAccess implementation. We would want
> to require that this header be sent with every single response for a
> browser to actually surface the contents of the request. A call to a
> "canAccess" method triggering a HEAD request would enable developers
> to surface a generic error to their end-users without unnecessarily
> pounding the XML service. But a service might elect to "change its
> mind" about who may access it between two "canAccess" call.  The
> question I'd ask now is how long should a user-agent cache a failure
> to access a remote service. Should it?
> 
>   - how long should it cache a failure to access from a canAccess call ?
>   - how long should it cache a failure to access from a regular open("GET") ?
> 
> 
> On Wed, 9 Mar 2005 12:26:36 -0600, Doron Rosenberg <doronr at gmail.com> wrote:
> > In Mozilla, Web Services opted to use a model where the web serivices
> > provider could define what hosts can call it:
> > http://lxr.mozilla.org/seamonkey/source/extensions/webservices/docs/New_Security_Model.html
> >
> > Macromedia did a similar thing for Flash's webservices code.
> >
> > We could easily extend this model to XMLHTTPRequest.
> >
> >
> > On Tue, 8 Mar 2005 14:21:35 -0800, Chris Holland <frenchy at gmail.com> wrote:
> > > Note to moderators: please discard the duplicate of this email
> > > awaiting moderation. I had sent it before joining the list. Sorry
> > > about that :)
> > >
> > > Hi all :)
> > >
> > > I was hoping some of you might be able to give me some feedback on an
> > > informal RFC i put together on my blog:
> > >
> > > http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
> > >
> > > I'm basically looking to enable some sort of cross-host *and*
> > > cross-domain interoperability between documents via a modified clone
> > > of the XmlHttpRequest object, while attempting to tread very carefully
> > > on various security issues, such as Cookies and Basic-Auth
> > > credentials. A "ContextAgnosticXmlHttpRequest" would be a new object
> > > developers could use, beyond the traditional XmlHttpRequest.
> > >
> > > i'm not crazy about the ContextAgnostic* prefix ... but that's all i
> > > could come-up with so-far.
> > > It would obviously have a very very limited use and would absolutely
> > > not negate the usefulness of an XmlHttpRequest.
> > >
> > > I would look to use such object with non-transactional RESTful services/APIs
> > >
> > > thank you for your time :)
> > >
> > > --
> > > Chris Holland
> > > http://chrisholland.blogspot.com/
> > >
> > > --
> > > Chris Holland
> > > http://chrisholland.blogspot.com/
> > >
> >
> 
> --
> Chris Holland
> http://chrisholland.blogspot.com/
> 

-- 
Chris Holland
http://chrisholland.blogspot.com/