We should add newChannel2() with the following interface to nsIProtocolHandler; > nsIChannel newChannel2(in nsIURI aURI, > in nsIDOMDocument aRequestingDocument, > in nsIPrincipal aRequestingPrincipal, > in unsigned long aSecurityFlags, > in unsigned long aContentPolicyType); Once that interface is landed we can start migrating consumers to use newChannel2() rather than newChannel() to create a channel.

So, the main tricky thing here is that nsIProtocolHandler might be implemented by addons. So even if we add newChannel2 we can't rely on it being implemented. So here is what I suggest that we do: 1. Add nsIIOService.newChannel2/newChannelFromURI2. 2. Add nsIProtocolHandler.newChannel2 similar to what you're proposing in comment 0 (though see feedback below). 3. Add a nsSecurityCheckingWrapperChannel class. The constructor for this class would take an nsIChannel instance and forward all calls to that nsIChannel. However when AsyncOpen2 is called, it does security checks before forwarding the call to the inner channel's AsyncOpen function. 4. Make ioservice.newChannel2/newChannelFromURI2 first call nsIProtocolHandler.newChannel2. If that succeeds, return the created channel. If that fails, call nsIProtocolHandler.newChannel, but also create a nsSecurityCheckingWrapperChannel wrapping the returned channel.

I also think we might want to make the nsIProtocolHandler interface be > nsIChannel newChannel2(in nsIURI aURI, in nsILoadInfo aLoadInfo); This way we only need to create loadinfos in the io-service, rather than in each protocol handler.

Just Adding newChannel2 that takes a loadInfo and have newChannel call NewChannel2 with a null loadInfo. Please note, that this patch does not attach the loadInfo to the channel, this is still done in NS_NewChannel in nsNetutil.h. It will be a separate bug to attach the loadInfo in NewChannel.

Comment on attachment 8498889 [details] [diff] [review] protocolhandler_newchannel2.patch Review of attachment 8498889 [details] [diff] [review]: ----------------------------------------------------------------- We really have to make sure to make all of the newChannel2 implementations also set the loadinfo. But we can do that separately. ::: netwerk/protocol/app/AppProtocolHandler.cpp @@ +466,5 @@ > return NS_OK; > } > > +// We map app://ABCDEF/path/to/file.ext to > +// jar:file:///path/to/profile/webapps/ABCDEF/application.zip!/path/to/file.ext Leave this comment at NewChannel2 since eventually NewChannel is going to go away.

Carrying over r+. Just forgot to rev the uuid in the idl.