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
