BTW: I ask myself why we need a global mutex to protect a pool. Wouldn't
a thread mutex be sufficient?
I figured accessing a pool inside a module config is something that needs
to be protected across process boundaries, hence the global lock. Are
module configs not globally unique in the sense
-Original Message-
From: Roy T. Fielding
Sent: Donnerstag, 9. Mai 2013 00:36
To: dev@httpd.apache.org
Subject: Re: svn commit: r1480058 - in /httpd/httpd/trunk: CHANGES
modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c
modules/proxy/proxy_util.c
On May 8, 2013, at
On 05/14/2013 08:58 PM, minf...@apache.org wrote: Author: minfrin
Date: Tue May 14 18:58:06 2013
New Revision: 1482522
URL: http://svn.apache.org/r1482522
Log:
core: Stop the HTTP_IN filter from attempting to write error buckets
to the output filters, which is bogus in the proxy case.
On 15 May 2013, at 9:48 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com wrote:
This causes new errors / regressions in the test suite.
Failed Test Stat Wstat Total Fail Failed List of Failed
On 14 May 2013, at 11:56 PM, Roy T. Fielding field...@gbiv.com wrote:
I am currently getting to the bottom of a test case that checks httpd's
response to an abnormally large chunk extension from a reverse proxy server.
What httpd does now is trigger an error, causing both the upstream and
-Original Message-
From: Graham Leggett [mailto:minf...@sharp.fm]
Sent: Mittwoch, 15. Mai 2013 10:59
To: dev@httpd.apache.org
Subject: Re: svn commit: r1482522 - in /httpd/httpd/trunk: ./ docs/log-
message-tags/ include/ modules/dav/main/ modules/generators/
modules/http/
On 15 May 2013, at 11:05 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com wrote:
# testing : response codes
# expected: HTTP/1.1 413 Request Entity Too Large
# received: HTTP/1.1 200 OK
not ok 7
Found further cases where error messages were being ignored, fixed in r1482918.
Graham Leggett wrote:
On 15 May 2013, at 11:05 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com wrote:
# testing : response codes
# expected: HTTP/1.1 413 Request Entity Too Large
# received: HTTP/1.1 200 OK
not ok 7
Found further cases where error messages were being
On 15 May 2013, at 9:23 PM, Ruediger Pluem rpl...@apache.org wrote:
Now we have:
t/apache/pr17629.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 4
I get this:
t/apache/pr17629.t ..
1..0 # skipped: cannot find module 'case_filter'
skipped: cannot find module 'case_filter'
Files=1,
Ugg. You're 100% right. We need to create a global.
On May 14, 2013, at 3:35 PM, Nick Kew n...@webthing.com wrote:
On 14 May 2013, at 19:54, Graham Leggett wrote:
Hi all,
I am currently getting a segfault in the proxy during httpd-test, it looks
like conf-mutex is being used before
On 16 May 2013, at 1:25 AM, Jim Jagielski j...@jagunet.com wrote:
Ugg. You're 100% right. We need to create a global.
Here is one I made earlier: http://svn.apache.org/r1482859
Regards,
Graham
--
Just wondering if we also have a problem with the pool
as well... if base doesn't have a proxy, we don't have
the subpool.
BTW, wondering if instead of leaking proxy_mutex we
could set ps-mutex = proxy_mutex in mod_proxy.c when
we merge. We could then make proxy_mutex static...?
On May 15, 2013,
Hmmm... The other idea is to keep it as it was,
stick pconf back in conf-pool but just always create
a sub-pool before conf-pool is used. This *looks*
like it removes the need for a mutex...
On May 15, 2013, at 7:37 PM, Jim Jagielski j...@jagunet.com wrote:
Just wondering if we also have a
13 matches
Mail list logo
