A goal of the implementation is that it should be reusable for other things than XMLHttpRequest. For example document.load should be able to do the same cross-site loads with the same restrictions. As should XSLT and XBL.
One tricky aspect is To do this we'll set up an [http://lxr.mozilla.org/mozilla/source/netwerk/base/public/nsIStreamListener.idl nsIStreamListener] that sits between the normal nsIStreamListener and the [http://lxr.mozilla.org/mozilla/source/netwerk/base/public/nsIChannel.idl nsIChannel]. Once onStartRequest is called we check for access control information can show up in two placesheaders. Both as HTTP If the headers, and as PIs inside XML filesdeny access we cancel the channel with a network error failure. Because of this it is suggested that If headers allow access we pass through all calls to the implementation has two parts:outer caller.
* An [http://lxrIf headers don't say either way and the content type is an XML one (do we have a good way to determine that?) we set up a parser and ourselfs as sink.mozillaWe'll then listen to notifications until the first start-element notification.org/mozilla/source/netwerk/base/public/nsIRequestObserver.idl nsIRequestObserver] At the same time we have to store all incoming data that checked is fed to the headers during onStartRequestparser. The observer is given If the uri of the requesting page when created and if the page access control PIs doesn't have indicate that access throws an exception thereby aborting should be granted we cancel the request. The observer act as a wrapper and forwards all calls to the existing nsIRequestObserver implementation (in the case of XMLHttpRequest the [http://lxr.mozilla.org/mozilla/source/content/base/src/nsXMLHttpRequest.cpp nsXMLHttpRequest] class)channel.
* A flag in [http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsExpatDriver.cpp nsExpatDriver] that makes the driver not send any notifications to the sink until either it has passed the matched an If access control PI, or it has reached the first element without finding a matching PI. If access should be denied the sink is canceled and we need to signal back to the XMLHttpRequest that loading failed. Unfortunately gecko architecture forces us to create a document before granted we create an nsExpatDriver. In fact, I'm not sure there is a way forward calls to even know that an nsExpatDriver will be created other than by calling [http://lxr.mozilla.org/mozilla/source/content/base/public/nsIDocument.h#148 StartDocumentLoad] on the document. We could possibly set up a dummy document until we get word from the nsExpatDriver that the access checks were successful and if they are set up a real document and restart the load. If we set up a dummy document it might be possible to do all this inside the nsIRequestObserver wrapper if we expand it into an nsIStreamListener. It would set up a dummy document and while streaming data into its streamlistener also copy all received data. If access control checks pass we could simply call into the outer listener caller and stream all copied the buffered data to it. In fact we wouldn't even need to create a dummy document. We could simply set up a custom sink that just checks the incoming processing instructions until the first element. This could even be implemented by the same object as the nsIRequestObserver wrapper.
=== Issues ===
* If the We have to check in onStartRequest fails, should we call the wrapping onStartRequest? The nsIRequestObserver interfaces says we must, but there is no way to indicate that the request is aborted. Or will canceling the request indicate that? * If we set up the dummy document inside the nsIRequestObserver wrapper, will it matter that we call code in onStartRequest on in the outer listener not until we've passed the access checks? Does data disappear from the channel once data start coming in? Maybe we could call onStartRequest even though we donoriginal streamlistener doesn't know do things that are too late to do once the load delayed onStartRequest is going to succeed? This would allow things like mimetype overrides to XML to work seamlessly I think. We'd have to watch out for this causing onreadystatechange requests to be firedcalled.
== Security worries ==
* We have to make sure to not put data in .responseText until we've passed access control checks even for XML files.
* We have to make it impossible to distinguish between a access-control-failed error and network errors such as 404s. Can the implementation "recancel" a canceled channel?
* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)
