-Original Message-
From: Joe Orton Sent: Montag, 23. Juli 2012 22:06
To: dev@httpd.apache.org
Subject: Re: ProxyBlock question
On Mon, Jul 23, 2012 at 03:41:19PM -0400, Eric Covener wrote:
b) if it's not the desired behaviour, that's a lot more messy.
I had assumed this
On 24.07.2012 08:58, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Joe Orton Sent: Montag, 23. Juli 2012 22:06
To: dev@httpd.apache.org
Subject: Re: ProxyBlock question
On Mon, Jul 23, 2012 at 03:41:19PM -0400, Eric Covener wrote:
b) if it's not the desired
-Original Message-
From: Rainer Jung [mailto:
Sent: Dienstag, 24. Juli 2012 09:40
To: dev@httpd.apache.org
Subject: Re: ProxyBlock question
On 24.07.2012 08:58, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Joe Orton Sent: Montag, 23. Juli 2012
On Tue, Jul 24, 2012 at 07:55:27AM +, Plüm, Rüdiger, Vodafone Group wrote:
Thanks. The patch reminded me of a special situation where the patch
might not be suitable: If the forward proxy just forwards everything
to the next proxy e.g. because it cannot do DNS lookups of the target
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Dienstag, 24. Juli 2012 10:20
To: dev@httpd.apache.org
Subject: Re: ProxyBlock question
On Tue, Jul 24, 2012 at 07:55:27AM +, Plüm, Rüdiger, Vodafone Group
wrote:
Thanks. The patch reminded me of a special
On 24.07.2012 10:20, Joe Orton wrote:
On Tue, Jul 24, 2012 at 07:55:27AM +, Plüm, Rüdiger, Vodafone Group wrote:
Thanks. The patch reminded me of a special situation where the patch
might not be suitable: If the forward proxy just forwards everything
to the next proxy e.g. because it cannot
On Tue, Jul 24, 2012 at 10:46:12AM +0200, Rainer Jung wrote:
IMHO if the admin explicitely configured an IP in the ProxyBlock
list we should nevertheless check. For this case there's already a
somewhat related warning in the docs which we could enhance for this
new case.
It looks like we
On Tue, Jul 24, 2012 at 08:42:34AM +, Plüm, Rüdiger, Vodafone Group wrote:
So after this rant I come to the conclusion that your proposed approach is
the best:
Only compare the names and not the IP's in the proxy case.
Attached does this - any comments? I suppose this requires a major
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Dienstag, 24. Juli 2012 11:37
To: dev@httpd.apache.org
Subject: [PATCH] Re: ProxyBlock question
On Tue, Jul 24, 2012 at 08:42:34AM +, Plüm, Rüdiger, Vodafone Group
wrote:
So after this rant I come to the
On 24.07.2012 11:22, Joe Orton wrote:
On Tue, Jul 24, 2012 at 10:46:12AM +0200, Rainer Jung wrote:
IMHO if the admin explicitely configured an IP in the ProxyBlock
list we should nevertheless check. For this case there's already a
somewhat related warning in the docs which we could enhance for
-Original Message-
From: Rainer Jung [mailto:]
Sent: Dienstag, 24. Juli 2012 12:49
To: dev@httpd.apache.org
Subject: Re: ProxyBlock question
On 24.07.2012 11:22, Joe Orton wrote:
(But reading that code again, you also lead me to another bug; the use
of apr_sockaddr_ip_get()
On Tue, Jul 24, 2012 at 10:05:34AM +, Plüm, Rüdiger, Vodafone Group wrote:
Looks good. Slight optimization:
If addr == NULL we can just skip the whole while (conf_addr) {
loop.
Thanks to all for the feedback.
main fix: http://svn.apache.org/viewvc?rev=1365001view=rev
pool use fix:
Dear dev@,
I've been looking into mod_lua for some time now, and have created an
external library with lot of functions that make use of the AP/APR C API
(such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd
and sendfile support etc). While doing so, I've also thought about how
The test case for PR 45434 seems to have regressed across 2.2-2.4.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45434
I have not tried to understand the mechanics here, but a dumb
side-by-side analysis found a missing piece, below. 2.2 hardcodes this
as real + 11 but 2.4 uses the
On 24.07.2012 19:23, Cantor, Scott wrote:
I'm seeing a build bug on a Solaris box with a very recent GCC version against
the Apache 2.4 headers, which I'm wondering about.
All my AP_INIT_TAKE1 macros for command handling are failing with:
error: expected primary-expression before '.' token
On 24.07.2012 19:40, Joe Orton wrote:
The test case for PR 45434 seems to have regressed across 2.2-2.4.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45434
I have not tried to understand the mechanics here, but a dumb
side-by-side analysis found a missing piece, below. 2.2 hardcodes
Daniel Gruno wrote:
Dear dev@,
I've been looking into mod_lua for some time now, and have created an
external library with lot of functions that make use of the AP/APR C API
(such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd
and sendfile support etc). While doing so,
Rainer Jung wrote:
On 24.07.2012 19:40, Joe Orton wrote:
The test case for PR 45434 seems to have regressed across 2.2-2.4.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45434
I have not tried to understand the mechanics here, but a dumb
side-by-side analysis found a missing piece,
I'm seeing a build bug on a Solaris box with a very recent GCC version against
the Apache 2.4 headers, which I'm wondering about.
All my AP_INIT_TAKE1 macros for command handling are failing with:
error: expected primary-expression before '.' token
Looking at the macros, it's doing some kind of
On Jul 24, 2012, at 1:45 PM, Rainer Jung rainer.j...@kippdata.de wrote:
I can confirm, that I am able to build httpd 2.4 on Solaris using gcc 4.7.1.
I vaguely remember that I had also done it using 4.6.3. In my case no g++
involved though. That points in that direction as a possible
On 7/24/12 2:29 PM, Nick Kew n...@apache.org wrote:
Yes. It's not new: C++ doesn't like those macros.
Weird, never broke on me until now.
Simple fix is to enclose them in extern C { ... }.
Alternatively, expand them by hand as per C rules.
That was my next step, thanks.
-- Scott
21 matches
Mail list logo
