[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Chris Holland]

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/