On 09/19/2013 12:42 PM, Josh Matthews wrote:
I'm working on an experimental NavigationController
(https://github.com/slightlyoff/EventWorker/blob/master/explainer.md)
implementation for Gecko. Part of this work requires me to intercept
navigation requests before they turn into network requests and allow
content code to provide a synthesized response. I'm going to document
my current thinking and experiments for implementing this in Necko,
and then I'm hoping for feedback and/or suggestions for alternatives.
Focusing on nsHttpChannel for now, my avenue of attack is the following:
* split the code that runs in AsyncOpen into AsyncOpenSetup
(everything that sets headers on the channel) and FinishAsyncOpen
(everything that initiates an actual network request)
* create a new wrapper channel implementation that QIs to nsIChannel,
and contains the ability to inject an nsIInputStream which will be
passed to the wrapped channel's streamlistener callbacks.
* I am contemplating making this wrapper channel also QI to every
interface that nsHttpChannel implements and forward the calls that
should modify the underlying channel
This is incomplete, because fields like mResponseHead need to be
initialized, but I'm hoping for feedback as to whether this sounds
workable or not. Note that we also need the ability to continue the
original request (or perhaps a clone of it somehow) if the web content
decides not to intercept it. Any thoughts?
The general idea sounds fine.
+//XXXjdm make QI forward to mWrappedChannel, conditionally after AsyncOpen?
+// Problem - can't forward nsIChannel, and breaks QI contract in addition
The QI contract is an interesting issue. There are apparently at least
some addons that routinely wrap HttpChannels in JS, and those aren't
QI-able back and forth to the original channel, yet somehow it doesn't
break things too badly (bz knows more about that than I do). If it's
important to be able to QI to all the many IDLs that nsHttpChannel
supports, you could either implement all those methods (and just forward
the to the real channel when needed--lots of code but simple enough), or
you could have AlternateChannel inherit from nsHttpChannel (or in e10s,
HttpChannelChild), or even just make those classes implement
nsIAlternateSourceChannel. That makes me a little nervous
(nsHttpChannel is already plenty complicated), but at some level you're
just adding yet another pump type, so it might work.
Jason
Cheers,
Josh
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
