I am trying to use the Necko layer to do HTTP accesses, but for security reasons, the application needs control over what IP address is used for each access (it wants to make sure that a series of accesses to the same hostname all use the same IP addresses).
Attempt #1 Use URLs with IP addresses in them, and set a Host: header with the real hostname in it.
But doing that made web servers where several all use the same IP-address would sometimes end up returning cached data from the wrong server (because the cache code just uses the URL as the key, and doesn't know about the Host: that I set.)
Attempt #2 Make a class that implements nsIURI that wraps a another nsIURI but returns a different hostname for GetHost and GetAsciiHost (so the URL is the real URL, but the hostname is the particular IP address), and then set the Host: header back to the proper hostname.
But this didn't work, because trying to create a channel doesn't work on that wrapping URL.
So, what should I be doing...? Is there any way to convince the Cache to use an alternate URI/URL from the one that the rest of the HttpChannel is using? Or should I just extend #2 and make a wrapper class that implements nsStandardURL, since that seems to be the specific class that HttpChannel uses? (What needs to be true about the URI for HttpChannel to be happy with it?)
Is there some better technique to get the control that I want?
Thanks. William [EMAIL PROTECTED]
there are no good direct hooks for what you are trying to do. there is one that might work. you can filter all normal HTTP traffic (note: this does not include HTTPS traffic) through a PRFileDesc of your own. you can do this by implementing nsISocketProvider (see netwerk/socket/base).
register your nsISocketProvider implementation under a contract-id like so:
@mozilla.org/network/socket;2?type=foo
then, set the following pref:
pref("network.http.default-socket-type", "foo");
this should give you a way to intercept all low-level socket activity. your nsISocketProvider will be told the hostname that is being used. you will need to implement a layered PRFileDesc that wraps an ordinary TCP socket PRFileDesc. PSM currently does the same thing to implement support for SSL in a transparent-to-necko way. see:
security/manager/ssl/src/nsNSSIOLayer.cpp
for the PSM implementation of PRFileDesc and,
security/manager/ssl/src/nsSSLSocketProvider.cpp
for the PSM implementation of nsISocketProvider.
using this technique, you should be able to override the PRNetAddr passed into your connect method. another good example of this technique being used can be found here:
ipc/ipcd/client/src/ipcTransportUnix.cpp
in this example, necko is tricked into talking over a UNIX domain TCP socket instead of an IP domain socket.
hope this helps, darin
_______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib