FWIW, maybe we should deprecate nsIChannel::owner, and change the JAR channel to implement nsIJARChannel w/ a principal getter.
-Darin On 3/7/06, Darin Fisher <[EMAIL PROTECTED]> wrote: > So, if channels support nsIPropertyBag and they somehow dispatch a > notification to observers from AsyncOpen, then we could get around > needing nsISecureIOService. > > We could create a utility function for creating a channel with > principal that content and imagelib and other necko consumers could > all use. > > This way, necko doesn't really need to change that much. Moreover, > provided we make nsBaseChannel emit "on-modify-request" or some > similar callback from AsyncOpen, this will all work fine when > third-party protocol handlers use nsInputStreamChannel to satisfy > their NewChannel method. > > -Darin > > > On 3/7/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > > Darin Fisher wrote: > > > Yeah, I was thinking of generalizing it to some kind of method call on > > > the IO service that passes the channel and gives the IO service a > > > chance to abort the load. > > > > That would work quite nicely for what I want, if the channel has the > > required > > security context information attached to it (as you proposed). That would > > just > > require us to audit existing newChannel callers, which ought to be doable, > > I guess. > > > > -Boris > > _______________________________________________ > > 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
