What I didnt' find by looking in the Mozilla's network code is a way to
uniquely identify a request and be able to find its parent.
necko does not know what the "parent" is, in general (and it's not really well-defined in many cases anyway). We need to somehow fix that, but that's a huge undertaking and no one has yet proposed a reasonable implementation for it that I know of.
boris is right. this is hard to do. you can get some information by inspecting the defaultRequest attribute of the channel's loadgroup.
Some times, a same request gets a new object between OnModifyRequest and OnExamineResponse !
This should happen with any HTTP redirect, in fact.
actually, the http-on-examine-response observer topic fires for each redirected channel. and, http-on-modify-request is generated for the newly created channel.
i think what he is saying is that we sometimes create multiple nsHttpChannel instances for the same URI. that happens normally. for example, if the same piece of content is referenced in multiple places, then multiple requests will be made. in the case of <img> tags, imagelib tries to coalesce these loads so only one necko load will happen. however, if images are loaded from an <iframe> tag, then i think imagelib will not be involved until we discover the mime-type of the URL. in that case, multiple nsHttpChannels would be created. however, in such cases necko should utilize the cache to coalesce the loads behind a single network request. i would only expect the first nsHttpChannel instance to generate observer notifications (since those only happen when we make network requests).
-darin _______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib
