On 3/5/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > Darin Fisher wrote: > > Well, there must be some API somewhere to get the right context > > parameter to pass to necko, right? > > There ought to be by the time we're done with 1.9, yes. ;)
I guess I was trying to get you to describe that mechanism since getting the context is just as important as passing it along. Ignoring the async proxy call case for a second, the complexity of getting this context parameter and passing it to this API instead of nsIIOService's version, is no more or less error prone than remembering to push that context into a thread local store. So, I think it's important to consider how this context parameter will be used. Also, I think that this context API will require some modifications to the channel implementations. For example, any channel that issues a redirect will need to forward the context, right? What about third-party protocol handlers? What happens if a protocol handler does not forward the context from one channel to the next? Maybe we could use nsIPropertyBag to solve this problem since we can make our built-in channels support that interface and properties are automatically copied to a channel created via redirect. > > Yes, good point. You'd have to do more than just call NewURI. > > Note that I want this in newChannel, not newURI. We create plenty of URI > objects with no plans to load them (eg visited link checking). typo on my part. i get what you're after here. > > Maybe it would help me to understand where that comes from. > > "It depends". In the simplest setup, the context is the nsIPrincipal that > should be used for the security check. Where this comes from depends on the > details of what's being loaded, where, by whom, etc. OK.... so perhaps what we need from a necko point-of-view is a way to construct a channel with additional properties. And, then we can have that special new channel method call out to a global set of channel creation observers that can have access to the channel and the properties. > > Yes, this is something that I have always envisioned using those flags > > for. There are plenty of available bits. > > OK. I'd been hoping to be able to output a string representing the capability > that needs to be enabled to load the URI in some cases, but I guess I can just > use bits to express the common cases (allow, deny, chrome only, need universal > xpconnect, need universal browser write, need universal browser read)... hrm... can you take a moment to define what those mean for channels? for example, an file channel configured to upload data (to write data to disk) would seem to need universal browser write, whereas a file channel configured to read data would seem to need universal browser read. In other words, it doesn't seem to be sufficient to express those qualities on the singleton nsIProtocolHandler for the file protocol. -Darin _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
