On 12 Dec 2011, at 11:25 PM, William A. Rowe Jr. wrote:
I have a frustrating update, which we need to take into consideration for
the whole remote_ip-related resolution. From the httpd-ng workgroup...
This makes sense, we're an HTTP server, lets stick to RFC related terms.
Mark Nottingham
On 14 Dec 2011, at 12:50 AM, Graham Leggett wrote:
On 12 Dec 2011, at 11:25 PM, William A. Rowe Jr. wrote:
I have a frustrating update, which we need to take into consideration for
the whole remote_ip-related resolution. From the httpd-ng workgroup...
This makes sense, we're an HTTP
On Dec 13, 2011, at 5:33 PM, Graham Leggett wrote:
On 14 Dec 2011, at 12:50 AM, Graham Leggett wrote:
On 12 Dec 2011, at 11:25 PM, William A. Rowe Jr. wrote:
I have a frustrating update, which we need to take into consideration for
the whole remote_ip-related resolution. From the httpd-ng
On 12/13/2011 9:06 PM, Roy T. Fielding wrote:
On Dec 13, 2011, at 5:33 PM, Graham Leggett wrote:
On 14 Dec 2011, at 12:50 AM, Graham Leggett wrote:
On 12 Dec 2011, at 11:25 PM, William A. Rowe Jr. wrote:
I have a frustrating update, which we need to take into consideration for
the whole
I have a frustrating update, which we need to take into consideration for
the whole remote_ip-related resolution. From the httpd-ng workgroup...
On 09/12/2011, at 9:27 AM, William A. Rowe Jr. wrote to http-ng;
On 12/8/2011 12:33 PM, Karl Dubost wrote:
Le 8 déc. 2011 à 14:55, Larry Masinter a
On 22 Nov 2011, at 11:47 PM, Stefan Fritsch wrote:
I am not sure that we need that. When is it necessary versus the
information in the Host header? But if others think that it would be a
good idea, I am OK with it, too.
Looking at c-local_addr, it seems to be tied in with some other
fields
On 21 Nov 2011, at 8:04 PM, Stefan Fritsch wrote:
Looks reasonable. Some comments:
The error log handler log_remote_address for %a needs to fall back to
c-remote_ip if r is not specified. Otherwise one would need different
logformats for per-conn and per-request log messages. Also, I would
On 21 Nov 2011, at 8:04 PM, Stefan Fritsch wrote:
The error log handler log_remote_address for %a needs to fall back to
c-remote_ip if r is not specified. Otherwise one would need different
logformats for per-conn and per-request log messages. Also, I would
prefer %{r}a and %{c}a to force
On 22 Nov 2011, at 6:18 PM, Graham Leggett wrote:
I've noticed the %{c}a syntax isn't documented for either
error_log or access_log, should I update that or have I missed
something?
Oops, I meant the %{c}L syntax in mod_log_config. Will fix.
Regards,
Graham
--
On Tuesday 22 November 2011, Graham Leggett wrote:
On 21 Nov 2011, at 8:04 PM, Stefan Fritsch wrote:
Looks reasonable. Some comments:
The error log handler log_remote_address for %a needs to fall
back to c-remote_ip if r is not specified. Otherwise one would
need different logformats
On Sunday 20 November 2011, Graham Leggett wrote:
On 20 Nov 2011, at 1:37 AM, Jeff Trawick wrote:
On Sat, Nov 19, 2011 at 2:46 PM, Stefan Fritsch s...@sfritsch.de
wrote:
On Saturday 19 November 2011, Graham Leggett wrote:
The correction is simple; promote the remote_ip up to the
On 20 Nov 2011, at 1:37 AM, Jeff Trawick wrote:
On Sat, Nov 19, 2011 at 2:46 PM, Stefan Fritsch s...@sfritsch.de
wrote:
On Saturday 19 November 2011, Graham Leggett wrote:
The correction is simple; promote the remote_ip up to the request
rec and log/use for authentication that r-remote_ip
On 19 Nov 2011, at 4:49 AM, William A. Rowe Jr. wrote:
Nevermind that you failed to be consistent in tag values between
logging schemas...
Can you confirm in more detail what you're referring to? There is only
one logging line in the patch, and this was based on existing logging
lines in
On Saturday 19 November 2011, Graham Leggett wrote:
The correction is simple; promote the remote_ip up to the request
rec and log/use for authentication that r-remote_ip throughout
httpd. Introduce a wire client logging tag for c-remote_ip.
This is a lot simpler and cleaner I think, let
On Sat, Nov 19, 2011 at 2:46 PM, Stefan Fritsch s...@sfritsch.de wrote:
On Saturday 19 November 2011, Graham Leggett wrote:
The correction is simple; promote the remote_ip up to the request
rec and log/use for authentication that r-remote_ip throughout
httpd. Introduce a wire client
Hi all,
Right now, we only keep track of the real IP address of the incoming
connection within conn_rec, and with a simple webserver that's fine.
In a world containing load balancers, we now have the real IP address
(the load balancer) and the effective IP address (the IP that
connected
On Fri, Nov 18, 2011 at 8:24 AM, Graham Leggett minf...@sharp.fm wrote:
Hi all,
Right now, we only keep track of the real IP address of the incoming
connection within conn_rec, and with a simple webserver that's fine.
In a world containing load balancers, we now have the real IP address (the
On 18 Nov 2011, at 4:05 PM, Jeff Trawick wrote:
A. modules keep using conn_rec, core keeps track of TCP peer for
logging, post-read-request or some other per-request hook used to set
effective client in conn_rec
ugly updates to conn_rec by some module; client is really per-request
in some
On 18 Nov 2011, at 4:23 PM, Graham Leggett wrote:
The lines I was thinking along was that effective_ip was in addition
to the remote_ip, rather than instead of. The log format wouldn't
change, there would be a new value that would represent the
effective IP, in addition to the existing
On Friday 18 November 2011, Graham Leggett wrote:
besides the ugliness of updating conn_rec, are there known
functional drawbacks of the existing mechanism, assuming that
the module which sets the client also sets a note to allow
logging of the TCP peer if desired?
There is also the
Nevermind that you failed to be consistent in tag values between
logging schemas... nothing in this proposal addresses the reason
that I myself had implemented mod_remoteip, which was authn/authz
control. In the limited scenario you have considered, authn is
pretty much a noop on the physical
21 matches
Mail list logo
