perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
Date Mon, 13 Mar 2017 23:53:46 GMT
This has occurred in multiple contexts, including throwing segfaults in the
modperl test framework (connection handler, so no req_rec.)

Wondering if remoteip might be able to run a little bit earlier? This is all
relevant to what we are discussing about PROXY protocol enhancements.

On Mon, Mar 13, 2017 at 6:28 PM, JW <> wrote:
> ________________________________
> From: William A Rowe Jr <>
> To: JW <>
> Cc: "" <>
> Sent: Friday, March 10, 2017 1:44 PM
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
> On Thu, Mar 9, 2017 at 9:53 PM, JW <> 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 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:
>> But, $r->useragent_ip (wrongly) gives me 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,

Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
gives the remote ip with the PerlTransHandler and later stages. Thanks!

View raw message