On Sun, Nov 05, 2006 at 09:18:42PM +0100, Edi Weitz wrote:
On Thu, 02 Nov 2006 11:15:56 -0700, "Robert J. Macomber" tbnl@rojoma.com wrote: Hmm, I see the problem, but that actually wasn't the only situation this was written for. I also imagined proxies I wouldn't have control of like those used by, say, AOL customers.
To be honest, I didn't even know that chained proxies will add to the XFF header instead of just replacing it. Is this behaviour specified somewhere?
I'm not sure. I couldn't find a formal specification anywhere, but proxies (in particular Apache's mod_proxy, which is the one I'm concerned with) certainly do this, specified or not. Section 4.2 of RFC2616 requires multiple fields to be combined by appending new values onto the end, but I can't see anything that requires a proxy not to outright replace things.
Anyway, I was thinking that maybe a better API would look like this:
If there is no XFF header, return REMOTE-ADDR as it is now.
If there is a XFF header, return two values - the second one is a list of all IP addresses in the header, the first one is the last element of this list.
How about that?
Well, if you actually want the XFF header, there's always (header-in :x-forwarded-for) but this would save some processing. If you want the "real remote address", presumably you're thinking of looking past some known proxy (or chain of known proxies) and want the single address that came into it. I'm sure the "last address in the list" is the common case, though.
That's a roundabout way to say "yes, that sounds about right".
Oh, and on another note, COOKIE-OUT returns a (name . cookie) pair instead of just the cookie. Is there a reason for this? I'm pretty sure it's just a forgotten call to CDR.