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
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
On 22 Nov 2011, at 11:58 PM, Stefan Fritsch wrote:
From the thread, it is not clear to me that there was consensous on
how to fix it. Therefore I would vote for reverting r1070179 from 2.4,
fixing it in trunk, and then backporting the whole thing to 2.4 again
(maybe after 2.4.0).
In order to
On 22 Nov 2011, at 11:21 PM, Stefan Fritsch wrote:
from a cursory glance at mod_request and apreq, it seems that
mod_request offers a subset of the functionality of apreq. Graham, is
that correct?
If we aim for inclusion of apreq some time in 2.4.x, it may be a good
idea to not add another API
- Original Message -
On 22 Nov 2011, at 11:21 PM, Stefan Fritsch wrote:
from a cursory glance at mod_request and apreq, it seems that
mod_request offers a subset of the functionality of apreq. Graham,
is
that correct?
If we aim for inclusion of apreq some time in 2.4.x, it
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
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+rv = ap_pass_brigade(r-output_filters, bb);
+if (rv != APR_SUCCESS) {
+if (rv != AP_FILTER_ERROR) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, r,
+
+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
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
On Wed, Nov 23, 2011 at 08:37:31AM +0100, Kaspar Brand wrote:
There are two approaches to fix 1): a) turn off verify_hostname
where needed (t/ssl/pr12355.t and t/ssl/pr43738.t are doing this
right now) or b) specify the CA cert (generated in t/conf/ca/...)
to make verification work/succeed.
-1 for deprecation... mod_request's API is, imo, a bit
easier to stomach than apreq's
On Nov 22, 2011, at 4:21 PM, Stefan Fritsch wrote:
Hi,
from a cursory glance at mod_request and apreq, it seems that
mod_request offers a subset of the functionality of apreq. Graham, is
that correct?
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+rv = ap_pass_brigade(r-output_filters, bb);
+if (rv != APR_SUCCESS) {
+if (rv != AP_FILTER_ERROR) {
+
Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack
against certain mod_proxy/mod_rewrite configurations. A new CVE name,
CVE-2011-4317, has been assigned to this variant.
The configurations in question are the same as affected by -3368, e.g.:
RewriteRule ^(.*)
On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote:
Feel free to fix issues you find. That's the advantage of having it under
change control @apache.org.
I don't have time/inclination, thanks. If nobody has any interest in
maintaining this code, why has it been added to the tree? The
On Wed, Nov 23, 2011 at 9:15 AM, Jim Jagielski j...@apache.org wrote:
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
[snip]
+ rv = ap_pass_brigade(r-output_filters, bb);
+ if (rv != APR_SUCCESS)
Add in r1205419 and used in r1205423
On Nov 23, 2011, at 9:29 AM, Eric Covener wrote:
On Wed, Nov 23, 2011 at 9:15 AM, Jim Jagielski j...@apache.org wrote:
On Nov 23, 2011, at 7:07 AM, Igor Galić wrote:
[snip]
mod_negotiation: don't return non-AP_FILTER_ERROR filter return
values
On Wed, 23 Nov 2011 14:26:00 +
Joe Orton jor...@redhat.com wrote:
On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote:
Feel free to fix issues you find. That's the advantage of having it under
change control @apache.org.
I don't have time/inclination, thanks. If nobody has any
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Mittwoch, 23. November 2011 15:23
To: dev@httpd.apache.org
Subject: [RFC] further proxy/rewrite URL validation security
issue (CVE-2011-4317)
Prutha Parikh from Qualys reported a variant on the
On Wed, Nov 23, 2011 at 03:38:19PM +, Nick Kew wrote:
On Wed, 23 Nov 2011 14:26:00 +
Joe Orton jor...@redhat.com wrote:
On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote:
Feel free to fix issues you find. That's the advantage of having it under
change control
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
On Wed, 23 Nov 2011 16:21:44 +
Joe Orton jor...@redhat.com wrote:
On Wed, Nov 23, 2011 at 03:38:19PM +, Nick Kew wrote:
On Wed, 23 Nov 2011 14:26:00 +
Joe Orton jor...@redhat.com wrote:
On Sun, Nov 13, 2011 at 03:42:07AM +, Nick Kew wrote:
Feel free to fix issues
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
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
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
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
On Wed, 23 Nov 2011 20:29:40 +0200
Graham Leggett minf...@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
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
On Wed, 23 Nov 2011, j...@apache.org wrote:
Author: jim
Date: Wed Nov 23 15:01:42 2011
New Revision: 1205423
URL: http://svn.apache.org/viewvc?rev=1205423view=rev
Log:
Use ap_pass_brigade_fchk()
Modified:
httpd/httpd/trunk/modules/cache/mod_cache.c
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
On 23 Nov 2011, at 10:13 PM, Stefan Fritsch wrote:
-return OK;
+return ap_pass_brigade_fchk(r, out,
+apr_psprintf(r-pool,
+ cache_quick_handler(%s):
ap_pass_brigade returned,
+
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
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
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
On 11/23/2011 4:39 PM, Nick Kew wrote:
Appropriate Terminology Suggestion:
Object ProtocolRemote Name
-- --
request_rec HTTPClient client_ip
conn_recTCP Peer
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
When i delete exit(1), nothing has changed but when i commented out all the
mutexes it works, counter is working well. That's great. :)
that means shared memory is working well.
in terms of mutexes
i need to create mutex in post config
in handler
1. lock mutex
2. process global variable
3. unlcok
36 matches
Mail list logo
