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 wrote: > > From: William A Rowe Jr > To: JW > Cc: "modperl@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 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)
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 To: httpd ; modperl@perl.apache.org Cc: JW 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 wrote: > > From: William A Rowe Jr > To: JW > Cc: "modperl@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 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)
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 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 > To: httpd ; modperl@perl.apache.org > Cc: JW > 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 wrote: >> >> From: William A Rowe Jr >> To: JW >> Cc: "modperl@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 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! > >
