Darin, Thank you for your reply.
At the moment, I am leaning to using a nsISocketProvider as you suggest, and I am not particularly concerned about maintaining compatibility. However, if there would be any value for the Mozilla project if I worked with the nsIContentPolicy I am open to pitching in. Although it is not a requirement for me to intercept all http traffic (at least for now, https is excluded), it is a requirement that my filter sees all outbound URL requests since the filtering service works by rating URL's. So if I use the socket provider, there may be an impact on performance. I think I wil pursue the socket provider, and if the performance is severally hampered, them I will try the nsIContentPolicy route. Andrew "Darin Fisher" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Boris Zbarsky wrote: > > > Andrew Van Uitert wrote: > > > >> I need to have my filter sit at a level where it sees all http requests > >> before they hit the socket. The reason I have to sit so low, is that > >> many of > >> the porn sites use re-directs to pay other sites for their listings. > >> At the > >> XPCOM embed level I can only see the original URL, I never see any of > >> the > >> URL's that are downloaded as a result of a redirect. > > > > > > You can hook into redirects by implementing nsIHttpEventSink in the > > channel opener. See what nsURIChecker does at > > http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsURIChecker.cpp#360, > > for example... (and > > http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsURIChecker.cpp#206). > > > > > > -Boris > > _______________________________________________ > > Mozilla-netlib mailing list > > [EMAIL PROTECTED] > > http://mail.mozilla.org/listinfo/mozilla-netlib > > > Boris, I think that requires that he also controls the code that sets up > the HTTP requests. If I understand correctly, he wants to intercept all > HTTP requests made by the browser. > > Andrews, nsIContentPolicy is designed to help with what you are trying > to do. However, it has limitations. You can find an example of using > it to block content in the XPCOM book Creating XPCOM Components > <http://www.mozilla.org/projects/xpcom/book/cxc> written by Doug Turner > and Ian Oeschger. Look at the WebLock sample code. > > I would not recommend trying to intercept the HTTP protocol handler as > suggested by Christian. That is very difficult to do correctly. > > If you really want to intercept socket read and write calls, then you > can do so by implementing nsISocketProvider. There is a way to hook > your implementation of nsISocketProvider up as a "socket provider" for > all HTTP traffic. This allows you to easily wedge yourself between > Necko and the OS. > > See > http://lxr.mozilla.org/seamonkey/source/netwerk/socket/base/nsISocketProvider.idl > > You would need to write an XPCOM component that implements this > interface, and you would need to register it under the contract-id: > > [EMAIL PROTECTED]/network/socket;2?type=some-string/ > > where "some-string" is a name that you choose. > > Next you would need to set the following pref: > > pref("network.http.default-socket-type", "some-string"); > > That will cause all HTTP traffic to filter through your > nsISocketProvider implementation. Note, however, that other traffic > (notably HTTPS) will not go through your socket provider. > > A downside to all of these approaches is that they depend on non-frozen > Mozilla APIs. That means that a release of your software will not be > guaranteed to work with future versions of Mozilla. While it is > unlikely that these interfaces will change, it can and does happen from > time to time. If you are concerned about your software working with > future versions of Mozilla, then please let us know. There are things > you can do to write a component that will survive API changes without > causing a browser crash or some other badness. > > Darin _______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib
