[hunchentoot-devel] real-remote-addr and proxy chains

[Robert J. Macomber]

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 at 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:
> 
> 1. If there is no XFF header, return REMOTE-ADDR as it is now.
> 
> 2. 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.
-- 
Robert Macomber
tbnl at rojoma.com