You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2011/11/22 14:41:24 UTC
2.4.0….
I had hoped that we could have gotten 2.4.0 out kinda soon, but
with the wild-west kind of commits going on, there is a LOT
of stuff changed, willy-nilly, between 2.3.15-beta and the current
trunk on httpd-2.4...
So I have to ask: is the intent to really release 2.4.0 anytime soon,
or are is it a simple sandbox for people to play around in?
Re: 2.4.0….
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
>
> On Nov 22, 2011, at 8:48 AM, Graham Leggett wrote:
>
> > On 22 Nov 2011, at 3:41 PM, Jim Jagielski wrote:
> >
> >> I had hoped that we could have gotten 2.4.0 out kinda soon, but
> >> with the wild-west kind of commits going on, there is a LOT
> >> of stuff changed, willy-nilly, between 2.3.15-beta and the current
> >> trunk on httpd-2.4...
> >>
> >> So I have to ask: is the intent to really release 2.4.0 anytime
> >> soon,
> >> or are is it a simple sandbox for people to play around in?
> >
> > With v2.4.x being a real actual branch with the real actual
> > intention of being released within days or weeks, people are
> > trying out the betas, finding bugs and fixing them, and smoothing
> > over rough edges.
> >
> > Given that v2.4's API will be set in stone on the first release, we
> > need to make sure it is right.
>
>
> I'm fine with that... I just want to ensure that everyone's on the
> same page here ;)
How about we release another beta every week or two?
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: 2.4.0….
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 22, 2011, at 8:48 AM, Graham Leggett wrote:
> On 22 Nov 2011, at 3:41 PM, Jim Jagielski wrote:
>
>> I had hoped that we could have gotten 2.4.0 out kinda soon, but
>> with the wild-west kind of commits going on, there is a LOT
>> of stuff changed, willy-nilly, between 2.3.15-beta and the current
>> trunk on httpd-2.4...
>>
>> So I have to ask: is the intent to really release 2.4.0 anytime soon,
>> or are is it a simple sandbox for people to play around in?
>
> With v2.4.x being a real actual branch with the real actual intention of being released within days or weeks, people are trying out the betas, finding bugs and fixing them, and smoothing over rough edges.
>
> Given that v2.4's API will be set in stone on the first release, we need to make sure it is right.
I'm fine with that... I just want to ensure that everyone's on the
same page here ;)
Re: 2.4.0….
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Nov 2011, at 3:41 PM, Jim Jagielski wrote:
> I had hoped that we could have gotten 2.4.0 out kinda soon, but
> with the wild-west kind of commits going on, there is a LOT
> of stuff changed, willy-nilly, between 2.3.15-beta and the current
> trunk on httpd-2.4...
>
> So I have to ask: is the intent to really release 2.4.0 anytime soon,
> or are is it a simple sandbox for people to play around in?
With v2.4.x being a real actual branch with the real actual intention
of being released within days or weeks, people are trying out the
betas, finding bugs and fixing them, and smoothing over rough edges.
Given that v2.4's API will be set in stone on the first release, we
need to make sure it is right.
Regards,
Graham
--
Re: 2.4.0….
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 22, 2011, at 10:12 AM, Jeff Trawick wrote:
> On Tue, Nov 22, 2011 at 10:10 AM, Greg Ames <am...@gmail.com> wrote:
>>
>>
>> On Tue, Nov 22, 2011 at 9:15 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>>
>>>> So I have to ask: is the intent to really release 2.4.0 anytime soon,
>>>> or are is it a simple sandbox for people to play around in?
>>>
>>> It is safe to predict how that question would be answered ;)
>>>
>>> Alternately, "Let's plan for a RC this weekend, and I'll be asking all
>>> of us to put special effort towards testing the recent changes of your
>>> colleagues -- And nothing is a showstopper unless it is in the STATUS
>>> file Real Soon Now."
>>
>> I'd like to backport
>> http://svn.apache.org/viewvc?view=revision&revision=1203708 to 2.4. What's
>> the procedure? Are we in RTC mode now? Update STATUS and lobby for votes?
>
> Still CTR. (+1 from me anyway)
>
I agree...
For the record, it would be nice if we spent the rest of this week
ironing out issues in hopes for a RC sometime late next week...
Re: 2.4.0….
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 22, 2011 at 10:10 AM, Greg Ames <am...@gmail.com> wrote:
>
>
> On Tue, Nov 22, 2011 at 9:15 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> > So I have to ask: is the intent to really release 2.4.0 anytime soon,
>> > or are is it a simple sandbox for people to play around in?
>>
>> It is safe to predict how that question would be answered ;)
>>
>> Alternately, "Let's plan for a RC this weekend, and I'll be asking all
>> of us to put special effort towards testing the recent changes of your
>> colleagues -- And nothing is a showstopper unless it is in the STATUS
>> file Real Soon Now."
>
> I'd like to backport
> http://svn.apache.org/viewvc?view=revision&revision=1203708 to 2.4. What's
> the procedure? Are we in RTC mode now? Update STATUS and lobby for votes?
Still CTR. (+1 from me anyway)
Re: 2.4.0….
Posted by Greg Ames <am...@gmail.com>.
On Tue, Nov 22, 2011 at 9:15 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
> > So I have to ask: is the intent to really release 2.4.0 anytime soon,
> > or are is it a simple sandbox for people to play around in?
>
> It is safe to predict how that question would be answered ;)
>
> Alternately, "Let's plan for a RC this weekend, and I'll be asking all
> of us to put special effort towards testing the recent changes of your
> colleagues -- And nothing is a showstopper unless it is in the STATUS
> file Real Soon Now."
>
I'd like to backport
http://svn.apache.org/viewvc?view=revision&revision=1203708 to 2.4. What's
the procedure? Are we in RTC mode now? Update STATUS and lobby for votes?
Greg
Re: 2.4.0….
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 22, 2011 at 8:41 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I had hoped that we could have gotten 2.4.0 out kinda soon, but
> with the wild-west kind of commits going on, there is a LOT
> of stuff changed, willy-nilly, between 2.3.15-beta and the current
> trunk on httpd-2.4...
>
> So I have to ask: is the intent to really release 2.4.0 anytime soon,
> or are is it a simple sandbox for people to play around in?
It is safe to predict how that question would be answered ;)
Alternately, "Let's plan for a RC this weekend, and I'll be asking all
of us to put special effort towards testing the recent changes of your
colleagues -- And nothing is a showstopper unless it is in the STATUS
file Real Soon Now."
Re: 2.4.0….
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 22 November 2011, Nick Kew wrote:
> On Tue, 22 Nov 2011 22:17:50 +0100
>
> Stefan Fritsch <sf...@sfritsch.de> wrote:
> > There are two API changes left that I would like to have in 2.4:
> >
> > - add r->remote_ip
>
> Huh? Surely tcp details belong to the connection, and are
> accessible from the request_rec as r->conn->remote_ip ?
It's probably the best way to fix mod_remoteip. See the recent
"Effective IP address / real IP address" thread.
Re: 2.4.0….
Posted by Jim Jagielski <ji...@jaguNET.com>.
There is one other mod_proxy API that I'm muddling through,
and that's related to how we add balancers to a particular
vhost (not hard, pretty much done) but, more importantly, how
we dynamically add full vhost-like reverse proxies (extending
what mod_proxy_express does)...
For example, right now, the proxypass'es are all associated
with a particular server. So conceptionally:
<Virtualhost www.foo.com>
ProxyPass /img balancer://foo/
...
</Virtualhost>
<Virtualhost www.bar.com>
ProxyPass /img balancer://bar/
...
</Virtualhost>
What I'm looking at is something that allows the top-level
server (or the catch-all vhost) to provide something like
<Virtualhost www.bar.com>
ProxyPass /img balancer://bar/
ProxyPass http://www.example.com/ balancer://example/
...
</Virtualhost>
So a req for http://www.bar.com/img/apache.gif -> balancer://bar/apache.gif
and a req to the *same* vhost, but for http://www.example.com/img/apache.gif
goes to balancer://example/img/apache.gif
Lots of ways to do that, and am looking at a non-evasive
way right now, but I may require some tweaking of the proxy
structs...
Re: 2.4.0….
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 22, 2011, at 4:17 PM, Stefan Fritsch wrote:
> - add r->remote_ip
See discussion...
> - change the prototype of the error_log hook
+1
Re: client_ip vs remote_ip
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 23 November 2011, Graham Leggett wrote:
> On 23 Nov 2011, at 8:22 PM, Nick Kew wrote:
> >> This has the additional advantage of *breaking* existing
> >> c->remote_ip references and forcing the module author to choose
> >> which they mean for
> >> their purposes (most would refer to the authenticated address).
>
> This makes more sense to me, +1.
Yes, +1
> > An interesting take on it!
> >
> > But use of remote_ip and remote_addr goes further than that.
> > Changing their semantics in CGI (and its imitators from PHP to
> > mod_rewrite) would *silently* break apps, so a firm -1 to that.
> > And divorcing conn->remote_ip from the CGI/etc gets fearsomely
> > confusing!
>
> There is no option to silently break any app, the only way to get
> this functionality is for the administrator to actively enable a
> module like mod_remoteip (or similar module depending on your
> needs). In the word of load balancers, this behaviour is already
> well understood and supported.
Agreed.
Re: client_ip vs remote_ip
Posted by Graham Leggett <mi...@sharp.fm>.
On 23 Nov 2011, at 10:01 PM, Nick Kew wrote:
> Um, are you responding to an altogether different point to the
> one I was making?
Very possibly...
> 1. wrowe was suggesting changing the semantics of remote_ip in core.
I interpreted wrowe's suggestion as simply making a name change on the variable to make a clearer distinction between c->remote_ip (IP address of httpd and upstream device, maybe a load balancer), and r->remote_ip (by default the exact same IP, unless mod_remoteip or mod_zeus / etc is configured, in which case it's now the IP of the client as seen by the load balancer, which wants to stay invisible).
The semantics of the remote_ip is exactly the same in both cases - it contains the remote IP address of the client.
When you add a load balancer in front of a set of httpds, the load balancer obscures the client's IP address, as it is now a "man-in-the-middle". An administrator is now no longer able to use the standard httpd aaa stuff for authz, and loses the IP address in logging. For years load balancers have solved this problem using some means of revealing the client IP to the origin httpd (usually in a header), with a corresponding module like mod_remoteip or mod_zeus to override the IP address, but httpd has never had a clean way to allow this override to take place, as the IP address inside httpd is intimately wired into the connection, not the request. This fixes that, acknowledging that load balancers exist and properly allowing for them, without suffering hacks or leaks in our code.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/23/2011 2:01 PM, Nick Kew wrote:
> 3. so wrowe's suggestion implies we EITHER divorce "remote_ip" from
> REMOTE_IP (confusing!) OR change the semantics of REMOTE_IP and
> potentially break thousands of CGI/etc apps.
The later. We've already 'broken' thousands of CGI/etc apps throughout
the world, as many customers of mine either use a remote_ip style
solution or a much more trivial x-remote-ip header from their load
balancer to reroute it.
No reports of what grave ills this 'breakage' caused.
Care to offer one, any one?
Re: client_ip vs remote_ip
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 23 Nov 2011 20:29:40 +0200
Graham Leggett <mi...@sharp.fm> wrote:
> On 23 Nov 2011, at 8:22 PM, Nick Kew wrote:
>
> >> This has the additional advantage of *breaking* existing c->remote_ip
> >> references and forcing the module author to choose which they mean
> >> for
> >> their purposes (most would refer to the authenticated address).
>
> This makes more sense to me, +1.
>
> > An interesting take on it!
> >
> > But use of remote_ip and remote_addr goes further than that.
> > Changing their semantics in CGI (and its imitators from PHP to
> > mod_rewrite) would *silently* break apps, so a firm -1 to that.
> > And divorcing conn->remote_ip from the CGI/etc gets fearsomely
> > confusing!
>
> There is no option to silently break any app, the only way to get this
> functionality is for the administrator to actively enable a module
> like mod_remoteip (or similar module depending on your needs). In the
> word of load balancers, this behaviour is already well understood and
> supported.
Um, are you responding to an altogether different point to the
one I was making?
1. wrowe was suggesting changing the semantics of remote_ip in core.
2. but REMOTE_ADDR and REMOTE_IP are widely-used in CGI,
and everything else that uses CGI variables.
3. so wrowe's suggestion implies we EITHER divorce "remote_ip" from
REMOTE_IP (confusing!) OR change the semantics of REMOTE_IP and
potentially break thousands of CGI/etc apps.
--
Nick Kew
Re: client_ip vs remote_ip
Posted by Graham Leggett <mi...@sharp.fm>.
On 23 Nov 2011, at 8:22 PM, Nick Kew wrote:
>> This has the additional advantage of *breaking* existing c->remote_ip
>> references and forcing the module author to choose which they mean
>> for
>> their purposes (most would refer to the authenticated address).
This makes more sense to me, +1.
> An interesting take on it!
>
> But use of remote_ip and remote_addr goes further than that.
> Changing their semantics in CGI (and its imitators from PHP to
> mod_rewrite) would *silently* break apps, so a firm -1 to that.
> And divorcing conn->remote_ip from the CGI/etc gets fearsomely
> confusing!
There is no option to silently break any app, the only way to get this
functionality is for the administrator to actively enable a module
like mod_remoteip (or similar module depending on your needs). In the
word of load balancers, this behaviour is already well understood and
supported.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by Graham Leggett <mi...@sharp.fm>.
On 25 Nov 2011, at 4:16 PM, Jim Jagielski wrote:
>> Appropriate Terminology Suggestion:
>>
>> Object Protocol Remote Name
>> ------ -------- ------ ----
>> request_rec HTTP Client client_ip
>> conn_rec TCP Peer peer_ip
>
> Fine with me...
Done in r1206291. Assuming no problems, will backport this to v2.4 this weekend.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 23, 2011, at 5:39 PM, Nick Kew wrote:
> Appropriate Terminology Suggestion:
>
> Object Protocol Remote Name
> ------ -------- ------ ----
> request_rec HTTP Client client_ip
> conn_rec TCP Peer peer_ip
Fine with me...
Re: client_ip vs remote_ip
Posted by Graham Leggett <mi...@sharp.fm>.
On 24 Nov 2011, at 12:39 AM, Nick Kew wrote:
> Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI.
> Objection-in-principle to wrowe's suggestion withdrawn!
>
> How about, we make a clear break with possible confusion by
> dropping remote_ip altogether? It has wrowe's desired effect
> of forcing anyone who uses remote_ip to make a decision over
> what semantics are in fact needed.
>
> Appropriate Terminology Suggestion:
>
> Object Protocol Remote Name
> ------ -------- ------ ----
> request_rec HTTP Client client_ip
> conn_rec TCP Peer peer_ip
Sounds sensible, +1.
Regards,
Graham
--
Re: client_ip vs remote_ip
Posted by Rüdiger Plüm <ru...@vodafone.com>.
Am 24.11.2011 00:27, schrieb William A. Rowe Jr.:
> On 11/23/2011 4:39 PM, Nick Kew wrote:
>>
>> Appropriate Terminology Suggestion:
>>
>> Object Protocol Remote Name
>> ------ -------- ------ ----
>> request_rec HTTP Client client_ip
>> conn_rec TCP Peer peer_ip
>
> +1
>
>
+1
Regards
Rüdiger
Re: client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/23/2011 4:39 PM, Nick Kew wrote:
>
> Appropriate Terminology Suggestion:
>
> Object Protocol Remote Name
> ------ -------- ------ ----
> request_rec HTTP Client client_ip
> conn_rec TCP Peer peer_ip
+1
Re: client_ip vs remote_ip
Posted by Nick Kew <ni...@webthing.com>.
On 23 Nov 2011, at 18:22, Nick Kew wrote:
> But use of remote_ip and remote_addr goes further than that.
>
Whoops! No it doesn't: it's just REMOTE_ADDR that features in CGI.
Objection-in-principle to wrowe's suggestion withdrawn!
How about, we make a clear break with possible confusion by
dropping remote_ip altogether? It has wrowe's desired effect
of forcing anyone who uses remote_ip to make a decision over
what semantics are in fact needed.
Appropriate Terminology Suggestion:
Object Protocol Remote Name
------ -------- ------ ----
request_rec HTTP Client client_ip
conn_rec TCP Peer peer_ip
--
Nick Kew
Re: client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/23/2011 12:22 PM, Nick Kew wrote:
> On Wed, 23 Nov 2011 11:56:25 -0600
> "William A. Rowe Jr."<wr...@rowe-clan.net> wrote:
>
>> +1 to this rename, it's much more sensible than "effective", "phys",
>> "" et al, but reverse them.
>>
>> client_ip / client_addr is the immediate client of httpd, which may
>> be a load balancer or transparent proxy or normal proxy if mod_remoteip
>> has been introduced.
>
> Not really. The HTTP client is the end-of-line. The intermediary is
> an HTTP proxy, not a client.
Sorry. I mixed up 'client' with 'user agent' which are not exactly
interchangeable. A better word here?
>> remote_ip / remote_addr is the recognized _authenticated_ address.
>
> Indeed, that's terminology that goes right back to apache prehistory.
It is the intent of all users to leverage the end user's IP for authn.
That should be reflected in CGI etc below...
>> This has the additional advantage of *breaking* existing c->remote_ip
>> references and forcing the module author to choose which they mean for
>> their purposes (most would refer to the authenticated address).
>
> An interesting take on it!
>
> But use of remote_ip and remote_addr goes further than that.
> Changing their semantics in CGI (and its imitators from PHP to
> mod_rewrite) would *silently* break apps, so a firm -1 to that.
> And divorcing conn->remote_ip from the CGI/etc gets fearsomely
> confusing!
Ok... look, mod_remoteip does this today. Various x-remote-ip header
hacks do the same thing for load balancers. What would break? The
CGI values absolutely should be the end point (client's) address.
Graham asks us to restore the immediate-next agent's IP address, to
what ends I'm still not clear but apparently mainly for logging and
diagnostics (which was already supported by mod_remoteip for all
intermediary IPs). What he wants to do with the remaining remote
intermediaries is not apparent.
But his point is correct that it is challenging to track this in the
conn rec given our request lifetime scope, and the fact that the
successive clients on a single pipeline can and will change in many
proxy/balancer scenarios.
I completely agree remote_ip/addr is better tracked at req rec. We
would just need a variable name in the conn rec for the persistant
(default) ip address of the physical connection. And it seemed that
you like the breakage to steer developers at the variable really
of interest to them. client_ip wasn't it ;(
Re: client_ip vs remote_ip
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 23 Nov 2011 11:56:25 -0600
"William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> +1 to this rename, it's much more sensible than "effective", "phys",
> "" et al, but reverse them.
>
> client_ip / client_addr is the immediate client of httpd, which may
> be a load balancer or transparent proxy or normal proxy if mod_remoteip
> has been introduced.
Not really. The HTTP client is the end-of-line. The intermediary is
an HTTP proxy, not a client.
> remote_ip / remote_addr is the recognized _authenticated_ address.
Indeed, that's terminology that goes right back to apache prehistory.
> This has the additional advantage of *breaking* existing c->remote_ip
> references and forcing the module author to choose which they mean for
> their purposes (most would refer to the authenticated address).
An interesting take on it!
But use of remote_ip and remote_addr goes further than that.
Changing their semantics in CGI (and its imitators from PHP to
mod_rewrite) would *silently* break apps, so a firm -1 to that.
And divorcing conn->remote_ip from the CGI/etc gets fearsomely
confusing!
--
Nick Kew
client_ip vs remote_ip
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/23/2011 2:02 AM, Nick Kew wrote:
>
> On 22 Nov 2011, at 22:35, Graham Leggett wrote:
>
>> On 22 Nov 2011, at 11:45 PM, Nick Kew wrote:
>>
>>> Huh? Surely tcp details belong to the connection, and are accessible
>>> from the request_rec as r->conn->remote_ip ?
>>
>> They do until a load balancer comes along and sits in the way, obscuring the remote IP address. Suddenly the IP address is different on every request, even though the connection between httpd and the load balancer is constant and lasts a long time using keepalives.
>
> Wherein lies the problem. How confusing is it to have r->remote_ip
> and r->conn->remote_ip *and for them to be different*?
>
> These need distinct names to distinguish them!
> e.g. r->client_ip vs r->conn->remote_ip - obviously keep the latter!
+1 to this rename, it's much more sensible than "effective", "phys",
"" et al, but reverse them.
client_ip / client_addr is the immediate client of httpd, which may
be a load balancer or transparent proxy or normal proxy if mod_remoteip
has been introduced.
remote_ip / remote_addr is the recognized _authenticated_ address.
This has the additional advantage of *breaking* existing c->remote_ip
references and forcing the module author to choose which they mean for
their purposes (most would refer to the authenticated address).
Bill
Re: 2.4.0….
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1 for:
Having the "real" client ip stored in r->*
Some thought on name... I like r->client_ip but hold
no strong opinions ;)
On Nov 23, 2011, at 6:02 AM, Graham Leggett wrote:
> On 23 Nov 2011, at 10:02 AM, Nick Kew wrote:
>
>> Wherein lies the problem. How confusing is it to have r->remote_ip
>> and r->conn->remote_ip *and for them to be different*?
>>
>> These need distinct names to distinguish them!
>> e.g. r->client_ip vs r->conn->remote_ip - obviously keep the latter!
>
> We already have remote_ip exploded as remote_addr, and then we take remote_ip and put it into REMOTE_ADDR, adding yet another name to all of that will just add more confusion :(
>
> Regards,
> Graham
> --
>
Re: 2.4.0….
Posted by Graham Leggett <mi...@sharp.fm>.
On 23 Nov 2011, at 10:02 AM, Nick Kew wrote:
> Wherein lies the problem. How confusing is it to have r->remote_ip
> and r->conn->remote_ip *and for them to be different*?
>
> These need distinct names to distinguish them!
> e.g. r->client_ip vs r->conn->remote_ip - obviously keep the latter!
We already have remote_ip exploded as remote_addr, and then we take
remote_ip and put it into REMOTE_ADDR, adding yet another name to all
of that will just add more confusion :(
Regards,
Graham
--
Re: 2.4.0….
Posted by Nick Kew <ni...@webthing.com>.
On 22 Nov 2011, at 22:35, Graham Leggett wrote:
> On 22 Nov 2011, at 11:45 PM, Nick Kew wrote:
>
>> Huh? Surely tcp details belong to the connection, and are accessible
>> from the request_rec as r->conn->remote_ip ?
>
> They do until a load balancer comes along and sits in the way, obscuring the remote IP address. Suddenly the IP address is different on every request, even though the connection between httpd and the load balancer is constant and lasts a long time using keepalives.
Wherein lies the problem. How confusing is it to have r->remote_ip
and r->conn->remote_ip *and for them to be different*?
These need distinct names to distinguish them!
e.g. r->client_ip vs r->conn->remote_ip - obviously keep the latter!
--
Nick Kew
Re: 2.4.0….
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Nov 2011, at 11:45 PM, Nick Kew wrote:
> Huh? Surely tcp details belong to the connection, and are accessible
> from the request_rec as r->conn->remote_ip ?
They do until a load balancer comes along and sits in the way,
obscuring the remote IP address. Suddenly the IP address is different
on every request, even though the connection between httpd and the
load balancer is constant and lasts a long time using keepalives.
Regards,
Graham
--
Re: 2.4.0….
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 22 Nov 2011 22:17:50 +0100
Stefan Fritsch <sf...@sfritsch.de> wrote:
> There are two API changes left that I would like to have in 2.4:
>
> - add r->remote_ip
Huh? Surely tcp details belong to the connection, and are accessible
from the request_rec as r->conn->remote_ip ?
--
Nick Kew
Re: 2.4.0….
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 22 November 2011, Nick Kew wrote:
> On Tue, 22 Nov 2011 08:41:24 -0500
>
> Jim Jagielski <ji...@jaguNET.com> wrote:
> > I had hoped that we could have gotten 2.4.0 out kinda soon, but
> > with the wild-west kind of commits going on, there is a LOT
> > of stuff changed, willy-nilly, between 2.3.15-beta and the
> > current trunk on httpd-2.4...
> >
> > So I have to ask: is the intent to really release 2.4.0 anytime
> > soon, or are is it a simple sandbox for people to play around
> > in?
>
> Feature-and-core-API freeze? Aim for stable line rules:
> only bugfixes and cosmetics (outside of RTC at least).
There are two API changes left that I would like to have in 2.4:
- add r->remote_ip
- change the prototype of the error_log hook
After those, OK with me.
> Seems like a prerequisite for calling it stable!
Re: 2.4.0….
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 22 Nov 2011 08:41:24 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:
> I had hoped that we could have gotten 2.4.0 out kinda soon, but
> with the wild-west kind of commits going on, there is a LOT
> of stuff changed, willy-nilly, between 2.3.15-beta and the current
> trunk on httpd-2.4...
>
> So I have to ask: is the intent to really release 2.4.0 anytime soon,
> or are is it a simple sandbox for people to play around in?
Feature-and-core-API freeze? Aim for stable line rules:
only bugfixes and cosmetics (outside of RTC at least).
Seems like a prerequisite for calling it stable!
--
Nick Kew