You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/03/13 23:53:46 UTC
Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
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 <ga...@yahoo.com> wrote:
> ________________________________
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: JW <ga...@yahoo.com>
> Cc: "modperl@perl.apache.org" <mo...@perl.apache.org>
> 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 <ga...@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);
Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
gives the remote ip with the PerlTransHandler and later stages. Thanks!
Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Yes, that's an artifact of the phase in which we handle the remoteip
transposition. It could be slightly earlier which is why I raised the
question to the httpd dev community.
On Tue, Mar 14, 2017 at 12:31 AM, JW <ga...@yahoo.com> wrote:
>
> Don't know the answer to your question about remoteip ...
>
> However, what I noted is that the Apache remoteip module,
> when configured with "RemoteIPHeader X-Forwarded-For", deletes the
> X-Forwarded-For header.
> In the PerlPostReadRequestHandler stage, the X-Forwarded-For header
> exists and it seems Apache has yet to use the X-Forwarded-For value as
> $r->useragent_ip gives 127.0.0.1.
> In the next stage, PerlTransHandler, a call to $r->useragent_ip() gives the
> correct remote ip, but the X-Forwarded-For header is no longer available.
>
>
> ________________________________
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: httpd <de...@httpd.apache.org>; modperl@perl.apache.org
> Cc: JW <ga...@yahoo.com>
> Sent: Monday, March 13, 2017 4:53 PM
>
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> 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 <ga...@yahoo.com> wrote:
>> ________________________________
>> From: William A Rowe Jr <wr...@rowe-clan.net>
>> To: JW <ga...@yahoo.com>
>> Cc: "modperl@perl.apache.org" <mo...@perl.apache.org>
>> 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 <ga...@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);
>
> Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
> gives the remote ip with the PerlTransHandler and later stages. Thanks!
>
>
Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Yes, that's an artifact of the phase in which we handle the remoteip
transposition. It could be slightly earlier which is why I raised the
question to the httpd dev community.
On Tue, Mar 14, 2017 at 12:31 AM, JW <ga...@yahoo.com> wrote:
>
> Don't know the answer to your question about remoteip ...
>
> However, what I noted is that the Apache remoteip module,
> when configured with "RemoteIPHeader X-Forwarded-For", deletes the
> X-Forwarded-For header.
> In the PerlPostReadRequestHandler stage, the X-Forwarded-For header
> exists and it seems Apache has yet to use the X-Forwarded-For value as
> $r->useragent_ip gives 127.0.0.1.
> In the next stage, PerlTransHandler, a call to $r->useragent_ip() gives the
> correct remote ip, but the X-Forwarded-For header is no longer available.
>
>
> ________________________________
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: httpd <de...@httpd.apache.org>; modperl@perl.apache.org
> Cc: JW <ga...@yahoo.com>
> Sent: Monday, March 13, 2017 4:53 PM
>
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> 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 <ga...@yahoo.com> wrote:
>> ________________________________
>> From: William A Rowe Jr <wr...@rowe-clan.net>
>> To: JW <ga...@yahoo.com>
>> Cc: "modperl@perl.apache.org" <mo...@perl.apache.org>
>> 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 <ga...@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);
>
> Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
> gives the remote ip with the PerlTransHandler and later stages. Thanks!
>
>
Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
Posted by JW <ga...@yahoo.com>.
Don't know the answer to your question about remoteip ...
However, what I noted is that the Apache remoteip module,
when configured with "RemoteIPHeader X-Forwarded-For", deletes the
X-Forwarded-For header.
In the PerlPostReadRequestHandler stage, the X-Forwarded-For headerexists and it seems Apache has yet to use the X-Forwarded-For value as
$r->useragent_ip gives 127.0.0.1.
In the next stage, PerlTransHandler, a call to $r->useragent_ip() gives the
correct remote ip, but the X-Forwarded-For header is no longer available.
From: William A Rowe Jr <wr...@rowe-clan.net>
To: httpd <de...@httpd.apache.org>; modperl@perl.apache.org
Cc: JW <ga...@yahoo.com>
Sent: Monday, March 13, 2017 4:53 PM
Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
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 <ga...@yahoo.com> wrote:
> ________________________________
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: JW <ga...@yahoo.com>
> Cc: "modperl@perl.apache.org" <mo...@perl.apache.org>
> 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 <ga...@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);
Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
gives the remote ip with the PerlTransHandler and later stages. Thanks!