On Thu, Mar 9, 2017 at 9:53 PM, JW <gav...@yahoo.com> wrote: > > It's been over a month since moving to Apache 2.4. It was fairly > straightforward and required > little code to be updated, most of it Apache config. Everything runs as it > did before the update and I've > had no problems. The one function that didn't 'work' is described below. > > This mod_perl server is behind a proxy on the same machine. Under Apache > 2.2, $r->remote_ip() > returned 127.0.0.1 and not the user's actual IP. So, a > PerlPostReadRequestHandler extracted the user's > IP address from the X-Forwarded-For header and set it with $r->remote_ip( > $ip ). > > In Apache 2.4 (and mod_perl now) $c->remote_ip is split into > $r->useragent_ip and $c->client_ip: > http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html > But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be fixed > at some point (unless > I'm doing something wrong). So, for now, as above, the IP is extracted from > X-Forwarded-For > and set with $r->useragent_ip( $ip ).
Keep in mind you can't use r->useragent_ip until the request is created, e.g. the create request hook is not a good place to try this (we actually had to work around a crash related to this behavior in httpd's sources.) After the read_request phase, this information will be finalized (provided that the mod_remoteip config is correct). It seems some code was expecting to read the useragent_ip in a very early phase of connection handling, although the headers to populate it for the request had not even been read off the wire :) So now, all attempts to read this too-early will result in the c->client_ip values. Here's when the action happens; ap_hook_post_read_request(remoteip_modify_request, NULL, NULL, APR_HOOK_FIRST);
