mutex dir?
Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access /var/cache/httpd/mod_python/ (of course). So my question/request is, could you please make this directory set in the config? -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
[jira] Commented: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=comments#action_12366331 ] Sebastjan Trepca commented on MODPYTHON-111: OK, I understand and agree with your but then someone should change the documentation because now it says: A session will timeout if it has not been accessed for more than timeout, which defaults to 30 minutes. An attempt to load an expired session will result in a ``new'' session. From this line I thought accessing the session means that I execute the load() method, but I was apparantly wrong and spent few hours debugging my application and then few hours more for debugging mod_python. Can someone then please edit that line in docs and be more explicit about what that accessing means so people won't be confused when session will suddenly expire? Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Sebastjan Trepca updated MODPYTHON-111: --- Component: documentation Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: mutex dir?
On Tue, 14 Feb 2006, Jim Gallacher wrote: I wonder if we should generalize this, so rather than PythonMutexDir, we have PythonModuleConfig. Usage might look like: PythonModuleConfig mutex_dir /path/to/mutexs PythonModuleConfig max_mutex_locks 8 I may be wrong, but I think the reason this was never configurable was because the mutex is created before the apache config is read. Grisha
Re: Getting Started on mod_python 3.3.
Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). Regards, Nicolas 2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 Bash 3.1.X configure patches. I know that MODPYTHON-94 isn't a bug fix, but a few people have been after this one. Also MODPYTHON-113 may not seem important, but will mean that any test package I make available for new importer will work properly in all cases where module imports occur. Anyway, after trolling through JIRA, these seemed to be the important ones to me, but other might have other suggestions. Now, the question is how we manage this. Do we concentrate on these only in the trunk and get them out of the way first as a 3.2.X release, holding back any changes to test framework? Or do we merge such changes from trunk on a case by case basis in 3.2.X branch? Graham I was thinking about working on the new test framework in parallel of real work, away from the trunk (in my /branches/nlehuen directory). I don't think it will be too hard to track down the changes in the trunk tests and bring them back in the new test framework, but I may be wrong. One the new tests are available, I'll merge them back in the trunk. So I guess it's not necessary to hold back the next release do to the tests, and it may be a good exercise to due a few 3.2.x releases in a short period of time before doing the 3.3.x release. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). Regards, Nicolas Doh ! I've found the source code for Win32. I'll try to build it ASAP and give mod_python a try. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
Nicolas Lehuen wrote: Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now). I'm not sure we need *alot* of testing on *nix. The APR_STATUS_IS_SUCCESS macro is not an issue there, since it is defined as (rc == APR_SUCCESS), which is the change we've made anyway. That macro does have a different definition on Win32, so that's where the testing needs to happen. But if there is no Apache 2.2 for Win32, where does that leave us wrt to a release? After Graham's digging and the comments from Justin I'm much less concerned about a potential problem on Win32. I don't think we should pile a large number of changes in any given 3.2.x bugfix release. If each release has not deviated too much from the previous version, then we'll need to do less testing and can release more frequently. I'd hate to see us wait 2 or 3 months for 3.2.8 and find we have so many bug fixes, and little feature additions that we then need to go through another 3.2.8 beta cycle. Release early and release often. Jim Regards, Nicolas 2006/2/14, Nicolas Lehuen [EMAIL PROTECTED]: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 Bash 3.1.X configure patches. I know that MODPYTHON-94 isn't a bug fix, but a few people have been after this one. Also MODPYTHON-113 may not seem important, but will mean that any test package I make available for new importer will work properly in all cases where module imports occur. Anyway, after trolling through JIRA, these seemed to be the important ones to me, but other might have other suggestions. Now, the question is how we manage this. Do we concentrate on these only in the trunk and get them out of the way first as a 3.2.X release, holding back any changes to test framework? Or do we merge such changes from trunk on a case by case basis in 3.2.X branch? Graham I was thinking about working on the new test framework in parallel of real work, away from the trunk (in my /branches/nlehuen directory). I don't think it will be too hard to track down the changes in the trunk tests and bring them back in the new test framework, but I may be wrong. One the new tests are available, I'll merge them back in the trunk. So I guess it's not necessary to hold back the next release do to the tests, and it may be a good exercise to due a few 3.2.x releases in a short period of time before doing the 3.3.x release. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
On Tue, 14 Feb 2006, Nicolas Lehuen wrote: 2006/2/14, Graham Dumpleton [EMAIL PROTECTED]: [...] If we want to go down the path of having interim 3.2 bug rollup releases while 3.3 is being developed, might I suggest that we target the following for such a release in the near future. MODPYTHON-77 The Simplified GIL Aquisition patches. If this is the one where you get Restriction Execution errors upon launching a thread, then I'm kinda keen on seeing this fixed sooner than later. Just my $0.02. :-) Grisha
Testing mod_python SVN trunk with Apache 2.2 on Win32
Hi, I've built Apache 2.2 and tested mod_python SVN trunk with it. The two register_cleanup tests fail. Apparently it's because the test code registers a cleanup function giving the current request as parameter. Of course when the cleanup function is called, the request object is no longer valid, and Apache segfaults. Fixing this is only a matter of fixing the test code, yet I wonder how this code could properly run on Apache 2.0.55. Maybe the request object was not properly destroyed and this has been fixed in Apache 2.2 ? This also shows that we should document the fact that the current request object should not be passed directly or indirectly to the *.register_cleanup functions. Maybe we could implement a little test in those function to make sure it is not passed directly ? Those two failures aside, the rest of the tests are OK. Regards, Nicolas
corrupt cookie kills mod-perl / apreq
[note: x-posted to modperl]
[note: i sent this earlier from an unsubscribed address. that
shouldn't go through. if it does, apologies in advance ]
I wrote a web services module to incorporate the TrackBack protocol
into my mod_perl application
I started testing it using WordPress - the php blog software
It seems to have set a cookie (see details below) , that causes an
automatic error in modperl
The error in the logs is :Expected token not present
It was touched briefly in :
[mp2] Expected token not present error in logs
Date: Sun, 8 Jan 2006 11:18:10 -0500
The extent to which it was discussed was:
Joe Schaefer
It probably means that the request's Cookie: header was missing an
= sign.
Philip M. Gollucci
joes: any possibility of improving that error message in 2.07-dev ?
And then the conversation died.
The issue seems to be definitively caused by an issue in the way that
wordpress encodes the cookie and safari sends it
http://wordpress.org/support/topic/52813
http://www.darcynorman.net/2005/12/21/upgrading-blog-to-wp-20-rc3
From the headers_in , it seems that WordPress includes raw-php code
(instead of executing it), and either wordpress or safari doesn't
properly escape the = sign in the cookies.
In production I see little chance this will affect me or any other
user -- the invalid cookie isn't going to be sent to the box.
BUT it brings up this issue - a corrupt cookie of this sort seems to
call a die() in modperl once libapreq attempts to parse it. i'd say
50% of the dies are met with a segfault. i don't know why its not a
1:1 ratio.
I couldn't seem to find any way to provide a defense against this.
Just calling cookiejar-cookie() will cause the error.
my $cookiejar = Apache2::Cookie::Jar-new( $self-{'apr'} );
my @names = $cookiejar-cookies();
the segfault, natually, occurs whether or not the code is wrapped in
an eval block. an eval block didn't seem to catch the other error
either (sorry, but i can't discern what it is)
Can someone suggest an approach? Maybe some sort of validation regex
needs to be in/updated on the cookie parsing code? I'm a little
uneasy with the idea that sending a bad cookie gives a 50% chance to
segfault a server.
I've enclosed a Data::Dumper representation of the the APR::Table
headers_in atfer the cookie info. I'll be happy to pull it into any
other format if instructed how.
To recreate this, you can use:
wordpress-2.0.1 (current)
mac osx 10.4 + safari 2.0.3
libapreq 2.07
httpd 2.055
===
Created
193189633
Domain
g5.local
Expires
2007-02-14T23:47:13Z
Name
dbx-postmeta
Path
/
Value
grabit=0-,1-,2-,3-,4-,5-,6-amp;advancedstuff=0-,1+,2-
===
$headers_in = bless( {
'Accept' = '*/*',
'Accept-Language' = 'en',
'Accept-Encoding' = 'gzip, deflate',
'Cookie' =
'wordpressuser_c580712eb86cad2660b3601ac04202b2=admin;
wordpresspass_c580712eb86cad2660b3601ac04202b2=7ebeeed42ef50720940f5b8db
2f9db49; rs_session=59ae9b8b503e3af7d17b97e7f77f7ea5; dbx-
postmeta=grabit=0-,1-,2-,3-,4-,5-,6-advancedstuff=0-,1+,2-',
'User-Agent' = 'Mozilla/5.0 (Macintosh; U;
PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8',
'Connection' = 'keep-alive',
'Host' = 'g5.local:8082'
}, 'APR::Table' );
Re: svn commit: r377053 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
On Tue, Feb 14, 2006 at 12:02:24AM +0100, Ruediger Pluem wrote: On 02/13/2006 04:37 PM, Joe Orton wrote: On Sat, Feb 11, 2006 at 08:57:14PM -, [EMAIL PROTECTED] wrote: This change (I think) is triggering the bad pool ancestry abort() in the tables code: the proxy tests in the test suite are all dumping core in APR_POOL_DEBUG builds since yesterday. Here's a sample backtrace: Thanks for spotting this. You are correct: I used the wrong pool. p is actually the connection pool whereas the key / value pairs in r-headers_in get created from r-pool which lives shorter than the connection pool. Hopefully fixed by r377525. Could you please give it a try again? Great, thanks, that fixed all the proxy failures. joe
Re: svn commit: r371484 - /httpd/httpd/branches/async-read-dev/modules/ssl/ssl_engine_io.c
On 2/12/06, Brian Pane [EMAIL PROTECTED] wrote: to return different values for EAGAIN and please do a poll on readability for me vs. EAGAIN and please do a poll on writability for me. The connection state logic in the event MPM assumes that an EAGAIN result from an input filter means poll for readability, but in the case of SSL that's not necessarily true. Why can't it just poll for read/write if its an SSL socket? -- justin
Re: svn commit: r371484 - /httpd/httpd/branches/async-read-dev/modules/ssl/ssl_engine_io.c
Justin Erenkrantz wrote: On 2/12/06, Brian Pane [EMAIL PROTECTED] wrote: to return different values for EAGAIN and please do a poll on readability for me vs. EAGAIN and please do a poll on writability for me. The connection state logic in the event MPM assumes that an EAGAIN result from an input filter means poll for readability, but in the case of SSL that's not necessarily true. Why can't it just poll for read/write if its an SSL socket? -- justin Because as soon as the socket is free to write, poll will succeed. Bill
Re: Change in how to configure authorization
On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote: On 2/13/2006 at 8:39:41 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On Mon, Feb 13, 2006 at 08:26:39AM -0700, Brad Nicholes wrote: Yes, we do need to make this change. With the provider based rearchitecting of authentication in httpd 2.2, this left authorization in an unpredictable state especially when using multiple authorization types. You were never quite sure which one was going to happen first and had no way to order them or control them. With that, there was also a growing demand to be able to apply AND/OR logic to the way in which authorization is applied. So basically this change brings authorization up to the same level of power and flexibility that currently exists in httpd 2.2 for authentication. Hence being new functionality, there are bound to be bugs that need to be fixed, especially with backwards compatibility. So let's get the bugs identified and fixed. Could you have a look at making the test suite pass again, to that end? I tried to port mod_authany (c-modules/authany/mod_authany.c) to the trunk authz API, but to no avail. The tests which fail are: t/http11/basicauth..# Failed test 2 in t/http11/basicauth.t at line 24 FAILED test 2 Failed 1/3 tests, 66.67% okay t/security/CVE-2004-0811# Failed test 1 in t/security/CVE-2004-0811.t at line 14 # Failed test 2 in t/security/CVE-2004-0811.t at line 14 fail #2 # Failed test 3 in t/security/CVE-2004-0811.t at line 14 fail #3 # Failed test 4 in t/security/CVE-2004-0811.t at line 14 fail #4 FAILED tests 1-4 joe The other problem that I see in the configuration is that the Location /authany defines an authtype and authname but no authentication provider. This means that the authentication provider will default to 'file'. But since there hasn't been a password file specified either, the result is an AUTH_GENERAL_ERROR. This scenario would occur with either 2.2 or trunk. mod_authany is supposed to key off the AuthName configured for the location - if it's equal to authname then it kicks in and does the dummy authz hack. No argument that this is a weird hack, but this worked in 2.2 and earlier, is there any way it can do something similar without requiring a config file change? joe
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
On Feb 13, 2006, at 6:25 PM, Ruediger Pluem wrote: Then we should either find out or adjust it to the behaviour that we think is correct as the current behaviour doesn't seem to be. This looks to be an almost direct port from mod_jk, but I agree that the current behavior is quite strange :) So instead of worrying about why it is the way it is, I agree that we just fix what's there. We have a framework for true pooling, so let's just use that.;) Does the patched version pass the test framework? Have not checked so far. I did not manage to get the test framework running on my box so far. Can someone who has it running give it a try? That would be very nice. Although it's not really documented anyplace, it really is good practice for people who submit large changes to run them through the test framework first; it might be good to take same time and try to get it up and running, since it really does help track some things down... In the meantime, if you can send the latest patch, I'll test it here.
AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
-Ursprüngliche Nachricht- Von: Jim Jagielski On Feb 13, 2006, at 6:25 PM, Ruediger Pluem wrote: Although it's not really documented anyplace, it really is good practice for people who submit large changes to run That seems a reasonable good idea. them through the test framework first; it might be good to take same time and try to get it up and running, I will do so. since it really does help track some things down... In the meantime, if you can send the latest patch, I'll test it here. Currently I am away from my developing environment, but as soon as I get there (tonight German time) I will sent an updated version. Thanks in advance for running the tests. Regards Rüdiger
Re: mutex dir?
Oden Eriksson wrote: Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access /var/cache/httpd/mod_python/ (of course). So my question/request is, could you please make this directory set in the config? I assume you mean as an option to configure, rather than as an Apache configuration directive? Jim
[jira] Commented: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=comments#action_12366333 ] Jim Gallacher commented on MODPYTHON-111: - I'll update the documentation. Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: mutex dir?
tisdagen den 14 februari 2006 14.19 skrev Jim Gallacher: Oden Eriksson wrote: Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access /var/cache/httpd/mod_python/ (of course). So my question/request is, could you please make this directory set in the config? I assume you mean as an option to configure, rather than as an Apache configuration directive? I meant as an apache configuration directive. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: Currently I am away from my developing environment, but as soon as I get there (tonight German time) I will sent an updated version. Thanks in advance for running the tests. Anytime! :) I'm currently trying to trace through exactly how the code is trying to pool connections. Of course, we're only using reslist if we're a threaded MPM... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
AW: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
-Ursprüngliche Nachricht- Von: Jim Jagielski I'm currently trying to trace through exactly how the code is trying to pool connections. Of course, we're only using reslist if we're a threaded MPM... Really? I thought APR_HAS_THREADS is set when the OS supports threads. I thought that this is independent from the MPM we choose. Regards Rüdiger
Re: AW: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski I'm currently trying to trace through exactly how the code is=20 trying to pool connections. Of course, we're only using=20 reslist if we're a threaded MPM... Really? I thought APR_HAS_THREADS is set when the OS supports threads. I thought that this is independent from the MPM we choose. Yeah, but we check to see if we're 1 thread, so in prefork, we drop to single connection workers. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
lb_score
Off the top of my head, I have no idea why we even have lb_score rather than just using proxy_worker_stat as we should. This is easy to fix except for the fact that ap_get_scoreboard_lb() is AP_DECLARE... Of course, adjusting in HEAD is fine, but this is something that really should be fixed in 2.2, which means we have an API change. Comments?
AW: AW: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
-Ursprüngliche Nachricht- Von: Jim Jagielski Yeah, but we check to see if we're 1 thread, so in prefork, we drop to single connection workers. Which makes sense to me. Why have more than one connection per worker on a prefork processes that can only handle one request at a time? As the current connection pool mechanism is limited to share connections within the same process and not over all processes it is quite clear that prefork suffers a lot from this approach and the real benefit only shows up with a threaded MPM that has not too much processes. Whatever too much means. Regards Rüdiger
Re: lb_score
On Tuesday 14 February 2006 15:06, Jim Jagielski wrote:
Off the top of my head, I have no idea why we even have lb_score
Neither have I. Someone slipped it it; noone objected.
rather than just using proxy_worker_stat as we should.
This is easy to fix except for the fact that ap_get_scoreboard_lb()
is AP_DECLARE... Of course, adjusting in HEAD is fine, but
this is something that really should be fixed in 2.2, which
means we have an API change.
-1 for 2.2. Provisionally +1 for 2.4.
Comments?
This came up just yesterday on IRC. Brian would like to be able
to allocate some scoreboard space for his module. Metoo.
I haven't thought this through yet, but presumably we could implement
an API for this. Something like:
struct worker_score {
/* all the stuff that's there now */
void data[]; /* at the end */
};
/* ditto other records */
and an enum
enum { AP_SCOREBOARD_[GLOBAL|PROCESS|WORKER] ;} scoreboard_access_t;
then AP functions to allocate data bytes in a pre_mpm hook
with APR_HOOK_FIRST:
void ap_scoreboard_alloc_space(module* key, size_t nbytes, our enum);
and to retrieve them anywhere:
void* ap_scoreboard_get_data(module* key, our enum);
Then all we need is a table of offsets by module, to be set up before
the scoreboard is allocated and added in scoreboard_size,
scoreboard_init and accessors.
That leaves loadbalancers a proper API for attaching to the scoreboard,
and opens it to other modules.
--
Nick Kew
AW: lb_score
-Ursprüngliche Nachricht- Von: Jim Jagielski Off the top of my head, I have no idea why we even have lb_score rather than just using proxy_worker_stat as we should. This is easy to fix except for the fact that ap_get_scoreboard_lb() is AP_DECLARE... Of course, adjusting in HEAD is fine, but this is something that really should be fixed in 2.2, which means we have an API change. Comments? The problem is that we also need to change the scoreboard struct in scoreboard.h for this. So I guess we have an even bigger API change here. And if we change this, every future change to the proxy_worker_stat struct requires an API change that is not limited to the proxy. So I tend to say that we should change it on trunk, but not on 2.2. Regards Rüdiger
Recompiling modules for Apache 2.2.0
I am trying to recompile some modules from Apache 2.0 to use under 2.2.0, and get the following: In file included from /usr/local/apache2/include/ap_config.h:25, from /usr/local/apache2/include/httpd.h:43, from mod_rexx.h:72, from mod_rexx.c:25: /usr/local/apache2/include/apr.h:270: error: syntax error before 'r_off_t' /usr/local/apache2/include/apr.h:270: warning: type defaults to '' in declaration of 'apr_off_t' /usr/local/apache2/include/apr.h:270: warning: data definition has no type= or storage class In file included from /usr/local/apache2/include/apr_file_io.h:29, from /usr/local/apache2/include/apr_network_io.h:26, from /usr/local/apache2/include/httpd.h:53, from mod_rexx.h:72, from mod_rexx.c:25: /usr/local/apache2/include/apr_file_info.h:204: error: syntax error before 'apr_off_t' /usr/local/apache2/include/apr_file_info.h:204: warning: no semicolon at end of struct or union /usr/local/apache2/include/apr_file_info.h:206: warning: type defaults to '' in declaration of 'csize' and so on This appears to be caused by a missing typedef for off64_t and others, but I have run out of ideas on how to fix it. Any suggestions? don support (at) microtechniques.com
ap_proxy_initialize_worker_share
I've noticed in a few places where what is shared and what is not (ie: local to the worker struct within the child process) are confused. In my mind, ap_proxy_initialize_worker_share() should worry about things that are (possibly) shared, and thus worker-s entries. It should also be checking worker-s-status as well. Now ap_proxy_initialize_worker() contain worker specific items, and are therefore local to that child process. As such, checking to see if that worker has been initialized by checking worker-s-status ain't quite right, since it means that the *shared* data has been initialized, but that this worker may not have been (if you catch my drift). Furthermore, this means that the -cp stuff isn't being fully init'ed...
Re: AW: lb_score
Von: Jim Jagielski=20 =20 =20 Off the top of my head, I have no idea why we even have lb_score rather than just using proxy_worker_stat as we should. This is easy to fix except for the fact that ap_get_scoreboard_lb() is AP_DECLARE... Of course, adjusting in HEAD is fine, but this is something that really should be fixed in 2.2, which means we have an API change. =20 Comments? The problem is that we also need to change the scoreboard struct in scoreboard.h for this. So I guess we have an even bigger API change here. And if we change this, every future change to the proxy_worker_stat struct requires an API change that is not limited to the proxy. So I tend to say that we should change it on trunk, but not on 2.2. That was the reason I added the 'context' struct member, to allow for some reasonable extensions without adjusting the actual API. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: shutdown and linux poll()
Hi --
Does anyone have any advice? Does this seem like a problem
to be addressed? I tried to think through how one could signal
the poll()ing worker threads with pthread_kill(), but it seems
to me that not only would you have to have a signal handler
in the worker threads (not hard), you'd somehow have to break
out of whatever APR wrappers are abstracting the poll() once
the handler set its flag or whatever and returned -- the APR
functions can't just loop on EINTR anymore. (Is it
socket_bucket_read() in the socket bucket code and then
apr_socket_recv()? I can't quite tell yet.) Anyway, it seemed
complex and likely to break the abstraction across OSes.
Still, I imagine I'm not the only one who would really like
those worker threads to cleanly exit so everything else does ...
after all, they're not doing anything critical, just waiting
for the Keep-Alive timeout to expire, after which they notice
their socket is borked and exit.
Paul Querna wrote:
To clarify, are you sure its not using EPoll instead of Poll?
The culprit is the poll() inside apr_wait_for_io_or_timeout(),
which is indeed being called from within apr_socket_recv(). The
stack is, basically:
apr_wait_for_io_or_timeout()
apr_socket_recv()
socket_bucket_read()
apr_bucket_read()
ap_rgetline_core()
ap_rgetline()
read_request_line()
ap_read_request()
ap_process_http_connection()
Here's the tail of my strace, after I hacked on waitio.c to
spit out a write() just before and after polling:
11:47:21.757774 write(15, about to poll with timeout 15000\n, 33) = 33
11:47:21.757877 close(15) = 0
11:47:21.757943 munmap(0xb7fff000, 4096) = 0
11:47:21.758016 poll([{fd=14, events=POLLIN, revents=POLLNVAL}], 1,
15000) = 1
11:47:33.261025 +++ killed by SIGKILL +++
I'd really love to hear opinions on this. Would anyone like
a patch to make ap_reclaim_child_processes() to wait first for the
maximum configured Keep-Alive period?
If that's too hacky, then what's the consensus -- ignore the
issue, or try to invent a way for the worker (and event?) MPMs
to signal their worker threads? It would seem to me that,
other than major surgery on APR, the ideal would be for the
signal handler to perform this snippet from the tail of worker_thread():
ap_update_child_status_from_indexes(process_slot, thread_slot,
(dying) ? SERVER_DEAD : SERVER_GRACEFUL, (request_rec *) NULL);
apr_thread_exit(thd, APR_SUCCESS);
or at a bare minimum, the apr_thread_exit(). But I'm not sure
offhand if having signal handlers perform thread exits is possible;
I feel like it's verboten
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
AW: ap_proxy_initialize_worker_share
-Ursprüngliche Nachricht- Von: Jim Jagielski quite right, since it means that the *shared* data has been initialized, but that this worker may not have been (if you catch my drift). Furthermore, this means that the -cp stuff isn't being fully init'ed... Yep, see http://issues.apache.org/bugzilla/show_bug.cgi?id=38403#c15 as an example for uninitilized cp / res list stuff. Regards Rüdiger
AW: lb_score
-Ursprüngliche Nachricht- Von: Jim Jagielski That was the reason I added the 'context' struct member, to allow for some reasonable extensions without adjusting the actual API. :) Yes, but it is not possible to share this data over processes easily as it is only a pointer. Of course it makes perfect sense for data that stays local to the process. So if we want to add further shareable data to this struct we need to adjust the scoreboard API. Maybe Nicks ideas on an extended scoreboard API could be helpful to address this. Regards Rüdiger
Re: lb_score
Nick Kew wrote:
I haven't thought this through yet, but presumably we could implement
an API for this. Something like:
struct worker_score {
/* all the stuff that's there now */
void data[]; /* at the end */
};
/* ditto other records */
:)
I did this awhile ago on all the proxy structs, simply
to give us a back door there :)
That leaves loadbalancers a proper API for attaching to the scoreboard,
and opens it to other modules.
The only concern I see is the potential for pollution, and
stuff being in the scoreboard that's best as private
shared storage. For example, the LB stuff really didn't
have to be in the scoreboard, but could do quite well
as a nice shared mem segment pointer passed as part of
the module struct...
But making it easier to extend the scoreboard for stuff
that really must be universally shared is a big +1 :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Re: AW: AW: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski=20 =20 =20 Yeah, but we check to see if we're 1 thread, so in prefork, we drop to single connection workers. Which makes sense to me. To me too. What it's doing is correct. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: AW: lb_score
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski=20 =20 =20 That was the reason I added the 'context' struct member, to=20 allow for some reasonable extensions without adjusting the=20 actual API. :) Yes, but it is not possible to share this data over processes easily as it is only a pointer. But it could be a pointer to a shared memory segment :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
AW: AW: lb_score
-Ursprüngliche Nachricht- Von: Jim Jagielski Yes, but it is not possible to share this data over processes easily as it is only a pointer. But it could be a pointer to a shared memory segment :) Yes of course, but I have to write more code to manage this than for an element of the struct. Ok, I am way tooo lazy :-). Regards Rüdiger
Re: lb_score
Jim Jagielski wrote:
Nick Kew wrote:
I haven't thought this through yet, but presumably we could implement
an API for this. Something like:
struct worker_score {
/* all the stuff that's there now */
void data[]; /* at the end */
};
/* ditto other records */
:)
I did this awhile ago on all the proxy structs, simply
to give us a back door there :)
That leaves loadbalancers a proper API for attaching to the scoreboard,
and opens it to other modules.
The only concern I see is the potential for pollution, and
stuff being in the scoreboard that's best as private
shared storage. For example, the LB stuff really didn't
have to be in the scoreboard, but could do quite well
as a nice shared mem segment pointer passed as part of
the module struct...
But making it easier to extend the scoreboard for stuff
that really must be universally shared is a big +1 :)
+1
Bill
Re: mutex dir?
Oden Eriksson wrote: tisdagen den 14 februari 2006 14.19 skrev Jim Gallacher: Oden Eriksson wrote: Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in /var/cache/httpd/mod_python/. But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access /var/cache/httpd/mod_python/ (of course). So my question/request is, could you please make this directory set in the config? I assume you mean as an option to configure, rather than as an Apache configuration directive? I meant as an apache configuration directive. After giving this some thought I think it should be both, so the options become: 1. Default /tmp 2. --configure --with-mutex-dir=/some/directory Allows distributions to package mod_python according to their platform specification, without the need for applying any patches. 3. PythonMutexDir /some/place This would mainly be used in the unit tests to override the setting applied by option #2. This avoids Oden's unit test problem which is similar to the problem described in MODPYTHON-119, where the unit test defaults may conflict with a mod_python instance running on the server. I wonder if we should generalize this, so rather than PythonMutexDir, we have PythonModuleConfig. Usage might look like: PythonModuleConfig mutex_dir /path/to/mutexs PythonModuleConfig max_mutex_locks 8 Currently the number of mutex locks is set with ./configure --with-max-locks By the way Oden, are you the offical mod_python maintainer on Mandriva? Jim
Re: AW: AW: lb_score
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski=20 =20 Yes, but it is not possible to share this data over=20 processes easily=20 as it is only a pointer. =20 But it could be a pointer to a shared memory segment :) Yes of course, but I have to write more code to manage this than for an element of the struct. Ok, I am way tooo lazy :-). :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Apache 2.2.0 support?
Hello all--I'm sure this has been a subject of ongoing discussion; but could someone perhaps fill me in on the timeline for adding mod_python support for Apache 2.2.0? I just put together mod_python 3.2.7 and Apache 2.2.0 with Python 2.4.2, and it doesn't really work. Any clues why not, or ideas as to when it might would be welcomed. Or if these questions have already been answered, is there an archive of this list I could search? Thanks much.
Re: Change in how to configure authorization
On 2/14/2006 at 3:50 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote: The other problem that I see in the configuration is that the Location /authany defines an authtype and authname but no authentication provider. This means that the authentication provider will default to 'file'. But since there hasn't been a password file specified either, the result is an AUTH_GENERAL_ERROR. This scenario would occur with either 2.2 or trunk. mod_authany is supposed to key off the AuthName configured for the location - if it's equal to authname then it kicks in and does the dummy authz hack. No argument that this is a weird hack, but this worked in 2.2 and earlier, is there any way it can do something similar without requiring a config file change? joe This is where I am a little confused. The AUTH_GENERAL_ERROR is coming from the authn side not authz and nothing has really changed in authn between 2.2 and 2.3. So I don't understand how it worked in 2.2. Looking at the code again, I think you are still going to need the authany_handler() to handle the authentication. If mod_auth_basic tries to handle the authentication, then it will attempt to default to 'file' and fail as I mentioned before. In fact, everything that was working before should continue to work correctly. There is nothing to prevent a module from grabbing the same check_user_id and auth_checker hooks and handling them. Brad
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
On Feb 13, 2006, at 1:28 PM, William A. Rowe, Jr. wrote: Ruediger Pluem wrote: Currently I work on PR 38602 (http://issues.apache.org/bugzilla/ show_bug.cgi?id=38602). First of all the reporter is correct that we do not sent the Connection: Keep-Alive header on our HTTP/1.1 keep-alive connections to the backend. But this is only the small part of the problem since 8.1.2 of the RFC says: A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, The real problem is that we've never paid attention to the backend server. If speaking to a backend http/1.0 server, we can try connection: keep-alive if the server pays attention to it. That header is invalid for http/1.1 backends, and we should choose connection: close where appropriate. To a backend http/1.0 server, connection: close is meaningless (and wrong). IIRC, http/1.0 lacks any Connection header at all.
Re: Recompiling modules for Apache 2.2.0
On 2/14/06, System Support [EMAIL PROTECTED] wrote: I am trying to recompile some modules from Apache 2.0 to use under 2.2.0, and get the following: In file included from /usr/local/apache2/include/ap_config.h:25, from /usr/local/apache2/include/httpd.h:43, from mod_rexx.h:72, from mod_rexx.c:25: /usr/local/apache2/include/apr.h:270: error: syntax error before 'r_off_t' /usr/local/apache2/include/apr.h:270: warning: type defaults to '' in declaration of 'apr_off_t' /usr/local/apache2/include/apr.h:270: warning: data definition has no type= or storage class In file included from /usr/local/apache2/include/apr_file_io.h:29, from /usr/local/apache2/include/apr_network_io.h:26, from /usr/local/apache2/include/httpd.h:53, from mod_rexx.h:72, from mod_rexx.c:25: /usr/local/apache2/include/apr_file_info.h:204: error: syntax error before 'apr_off_t' /usr/local/apache2/include/apr_file_info.h:204: warning: no semicolon at end of struct or union /usr/local/apache2/include/apr_file_info.h:206: warning: type defaults to '' in declaration of 'csize' and so on This appears to be caused by a missing typedef for off64_t and others, but I have run out of ideas on how to fix it. Any suggestions? However you are compiling these modules you are most likely not passing the correct CFLAGS to the compiler. To use APR (as HTTPD does) you need to pass APR's CFLAGS, which you can get from apr-1-config --cflags. That'll allow off64_t to be correctly picked up from the system headers. -garrett
Re: Apache 2.2.0 support?
On 15/02/2006, at 5:07 AM, alex eh wrote: Hello all--I'm sure this has been a subject of ongoing discussion; but could someone perhaps fill me in on the timeline for adding mod_python support for Apache 2.2.0? I just put together mod_python 3.2.7 and Apache 2.2.0 with Python 2.4.2, and it doesn't really work. Any clues why not, or ideas as to when it might would be welcomed. Or if these questions have already been answered, is there an archive of this list I could search? The mailing list archives are available: http://mailman.modpython.org/mailman/listinfo/mod_python http://www.mail-archive.com/python-dev@httpd.apache.org/info.html If you need Apache 2.2 support now, use version of mod_python from subversion repository. http://svn.apache.org/viewcvs.cgi/httpd/mod_python/trunk Graham
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
Jim Jagielski wrote: To a backend http/1.0 server, connection: close is meaningless (and wrong). IIRC, http/1.0 lacks any Connection header at all. connection: keep-alive was a transitional http/1.0 behavior.
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
William A. Rowe, Jr. wrote: Jim Jagielski wrote: To a backend http/1.0 server, connection: close is meaningless (and wrong). IIRC, http/1.0 lacks any Connection header at all. connection: keep-alive was a transitional http/1.0 behavior. Yes, but not formal 1.0. (rfc1945) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: Apache 2.2.0 support?
Graham Dumpleton wrote: On 15/02/2006, at 5:07 AM, alex eh wrote: Hello all--I'm sure this has been a subject of ongoing discussion; but could someone perhaps fill me in on the timeline for adding mod_python support for Apache 2.2.0? I just put together mod_python 3.2.7 and Apache 2.2.0 with Python 2.4.2, and it doesn't really work. Any clues why not, or ideas as to when it might would be welcomed. Or if these questions have already been answered, is there an archive of this list I could search? The mailing list archives are available: http://mailman.modpython.org/mailman/listinfo/mod_python http://www.mail-archive.com/python-dev@httpd.apache.org/info.html If you need Apache 2.2 support now, use version of mod_python from subversion repository. http://svn.apache.org/viewcvs.cgi/httpd/mod_python/trunk Or apply the patch mentioned in MODPYTHN-78 to 3.2.7. See http://issues.apache.org/jira/browse/MODPYTHON-78. Jim
Re: AW: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
Jim Jagielski wrote: I'm currently trying to trace through exactly how the code is trying to pool connections. If someone produces a good patch, I have some traffic I can throw at it :) -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
On 02/14/2006 01:51 PM, Jim Jagielski wrote:
since it really does help track some things down... In the
meantime, if you can send the latest patch, I'll test
it here.
Please find attached
Changes to the previous one:
1. Diff against r377821.
2. I removed the !backend check also.
I am curious about the test results.
Regards
Rüdiger
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (Revision 377821)
+++ modules/proxy/proxy_util.c (Arbeitskopie)
@@ -1868,16 +1868,6 @@
conn-hostname = apr_pstrdup(conn-pool, uri-hostname);
conn-port = uri-port;
}
-}
-/*
- * TODO: add address cache for generic forward proxies.
- * At least level 0 - compare with previous hostname:port
- */
-if (r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE ||
-!worker-is_address_reusable) {
-/*
- * TODO: Check if the connection can be reused
- */
if (conn-connection) {
if (conn-sock) {
apr_socket_close(conn-sock);
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (Revision 377821)
+++ modules/proxy/mod_proxy_http.c (Arbeitskopie)
@@ -981,9 +981,18 @@
/* Yes I hate gotos. This is the subrequest shortcut */
skip_body:
-/* Handle Connection: header */
-if (!force10 p_conn-close) {
-buf = apr_pstrdup(p, Connection: close CRLF);
+/*
+ * Handle Connection: header if we do HTTP/1.1 request:
+ * If we plan to close the backend connection sent Connection: close
+ * otherwise sent Connection: Keep-Alive.
+ */
+if (!force10) {
+if (p_conn-close) {
+buf = apr_pstrdup(p, Connection: close CRLF);
+}
+else {
+buf = apr_pstrdup(p, Connection: Keep-Alive CRLF);
+}
ap_xlate_proto_to_ascii(buf, strlen(buf));
e = apr_bucket_pool_create(buf, strlen(buf), p, c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(header_brigade, e);
@@ -1510,12 +1519,6 @@
/* found the last brigade? */
if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(bb))) {
-/* if this is the last brigade, cleanup the
- * backend connection first to prevent the
- * backend server from hanging around waiting
- * for a slow client to eat these bytes
- */
-backend-close = 1;
/* signal that we must leave */
finish = TRUE;
}
@@ -1584,18 +1587,7 @@
apr_status_t ap_proxy_http_cleanup(const char *scheme, request_rec *r,
proxy_conn_rec *backend)
{
-/* If there are no KeepAlives, or if the connection has been signalled
- * to close, close the socket and clean up
- */
-
-/* if the connection is HTTP/1.1, or Connection: close,
- * we close the socket, otherwise we leave it open for KeepAlive support
- */
-if (backend-close || (r-proto_num HTTP_VERSION(1,1))) {
-backend-close_on_recycle = 1;
-ap_set_module_config(r-connection-conn_config, proxy_http_module,
NULL);
-ap_proxy_release_connection(scheme, backend, r-server);
-}
+ap_proxy_release_connection(scheme, backend, r-server);
return OK;
}
@@ -1673,26 +1665,13 @@
proxy: HTTP: serving URL %s, url);
-/* only use stored info for top-level pages. Sub requests don't share
- * in keepalives
- */
-if (!r-main) {
-backend = (proxy_conn_rec *) ap_get_module_config(c-conn_config,
- proxy_http_module);
-}
/* create space for state information */
-if (!backend) {
-if ((status = ap_proxy_acquire_connection(proxy_function, backend,
- worker, r-server)) != OK)
-goto cleanup;
+if ((status = ap_proxy_acquire_connection(proxy_function, backend,
+ worker, r-server)) != OK)
+goto cleanup;
-if (!r-main) {
-ap_set_module_config(c-conn_config, proxy_http_module, backend);
-}
-}
backend-is_ssl = is_ssl;
-backend-close_on_recycle = 1;
/* Step One: Determine Who To Connect To */
if ((status = ap_proxy_determine_connection(p, r, conf, worker, backend,
@@ -1732,10 +1711,8 @@
cleanup:
if (backend) {
-if (status != OK) {
+if (status != OK)
backend-close = 1;
-backend-close_on_recycle = 1;
-}
ap_proxy_http_cleanup(proxy_function, r, backend);
}
return status;
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
I'll test tomorrow morning... Heading out early today for Valentine's Day :) Ruediger Pluem wrote: This is a multi-part message in MIME format. --020401000706000306050001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/14/2006 01:51 PM, Jim Jagielski wrote: since it really does help track some things down... In the meantime, if you can send the latest patch, I'll test it here. Please find attached Changes to the previous one: 1. Diff against r377821. 2. I removed the !backend check also. I am curious about the test results. Regards Rüdiger --020401000706000306050001 Content-Type: text/plain; name=38602.diff Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=38602.diff SW5kZXg6IG1vZHVsZXMvcHJveHkvcHJveHlfdXRpbC5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG1v ZHVsZXMvcHJveHkvcHJveHlfdXRpbC5jCShSZXZpc2lvbiAzNzc4MjEpCisrKyBtb2R1bGVz L3Byb3h5L3Byb3h5X3V0aWwuYwkoQXJiZWl0c2tvcGllKQpAQCAtMTg2OCwxNiArMTg2OCw2 IEBACiAgICAgICAgICAgICBjb25uLT5ob3N0bmFtZSA9IGFwcl9wc3RyZHVwKGNvbm4tPnBv b2wsIHVyaS0+aG9zdG5hbWUpOwogICAgICAgICAgICAgY29ubi0+cG9ydCA9IHVyaS0+cG9y dDsKICAgICAgICAgfQotICAgIH0KLSAgICAvKgotICAgICAqIFRPRE86IGFkZCBhZGRyZXNz IGNhY2hlIGZvciBnZW5lcmljIGZvcndhcmQgcHJveGllcy4KLSAgICAgKiBBdCBsZWFzdCBs ZXZlbCAwIC0+IGNvbXBhcmUgd2l0aCBwcmV2aW91cyBob3N0bmFtZTpwb3J0Ci0gICAgICov Ci0gICAgaWYgKHItPnByb3h5cmVxID09IFBST1hZUkVRX1BST1hZIHx8IHItPnByb3h5cmVx ID09IFBST1hZUkVRX1JFVkVSU0UgfHwKLSAgICAgICAgIXdvcmtlci0+aXNfYWRkcmVzc19y ZXVzYWJsZSkgewotICAgICAgICAvKgotICAgICAgICAgKiBUT0RPOiBDaGVjayBpZiB0aGUg Y29ubmVjdGlvbiBjYW4gYmUgcmV1c2VkCi0gICAgICAgICAqLwogICAgICAgICBpZiAoY29u bi0+Y29ubmVjdGlvbikgewogICAgICAgICAgICAgaWYgKGNvbm4tPnNvY2spIHsKICAgICAg ICAgICAgICAgICBhcHJfc29ja2V0X2Nsb3NlKGNvbm4tPnNvY2spOwpJbmRleDogbW9kdWxl cy9wcm94eS9tb2RfcHJveHlfaHR0cC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG1vZHVsZXMvcHJv eHkvbW9kX3Byb3h5X2h0dHAuYwkoUmV2aXNpb24gMzc3ODIxKQorKysgbW9kdWxlcy9wcm94 eS9tb2RfcHJveHlfaHR0cC5jCShBcmJlaXRza29waWUpCkBAIC05ODEsOSArOTgxLDE4IEBA CiAKIC8qIFllcyBJIGhhdGUgZ290b3MuICBUaGlzIGlzIHRoZSBzdWJyZXF1ZXN0IHNob3J0 Y3V0ICovCiBza2lwX2JvZHk6Ci0gICAgLyogSGFuZGxlIENvbm5lY3Rpb246IGhlYWRlciAq LwotICAgIGlmICghZm9yY2UxMCAmJiBwX2Nvbm4tPmNsb3NlKSB7Ci0gICAgICAgIGJ1ZiA9 IGFwcl9wc3RyZHVwKHAsICJDb25uZWN0aW9uOiBjbG9zZSIgQ1JMRik7CisgICAgLyoKKyAg ICAgKiBIYW5kbGUgQ29ubmVjdGlvbjogaGVhZGVyIGlmIHdlIGRvIEhUVFAvMS4xIHJlcXVl c3Q6CisgICAgICogSWYgd2UgcGxhbiB0byBjbG9zZSB0aGUgYmFja2VuZCBjb25uZWN0aW9u IHNlbnQgQ29ubmVjdGlvbjogY2xvc2UKKyAgICAgKiBvdGhlcndpc2Ugc2VudCBDb25uZWN0 aW9uOiBLZWVwLUFsaXZlLgorICAgICAqLworICAgIGlmICghZm9yY2UxMCkgeworICAgICAg ICBpZiAocF9jb25uLT5jbG9zZSkgeworICAgICAgICAgICAgYnVmID0gYXByX3BzdHJkdXAo cCwgIkNvbm5lY3Rpb246IGNsb3NlIiBDUkxGKTsKKyAgICAgICAgfQorICAgICAgICBlbHNl IHsKKyAgICAgICAgICAgIGJ1ZiA9IGFwcl9wc3RyZHVwKHAsICJDb25uZWN0aW9uOiBLZWVw LUFsaXZlIiBDUkxGKTsKKyAgICAgICAgfQogICAgICAgICBhcF94bGF0ZV9wcm90b190b19h c2NpaShidWYsIHN0cmxlbihidWYpKTsKICAgICAgICAgZSA9IGFwcl9idWNrZXRfcG9vbF9j cmVhdGUoYnVmLCBzdHJsZW4oYnVmKSwgcCwgYy0+YnVja2V0X2FsbG9jKTsKICAgICAgICAg QVBSX0JSSUdBREVfSU5TRVJUX1RBSUwoaGVhZGVyX2JyaWdhZGUsIGUpOwpAQCAtMTUxMCwx MiArMTUxOSw2IEBACiAKICAgICAgICAgICAgICAgICAgICAgLyogZm91bmQgdGhlIGxhc3Qg YnJpZ2FkZT8gKi8KICAgICAgICAgICAgICAgICAgICAgaWYgKEFQUl9CVUNLRVRfSVNfRU9T KEFQUl9CUklHQURFX0xBU1QoYmIpKSkgewotICAgICAgICAgICAgICAgICAgICAgICAgLyog aWYgdGhpcyBpcyB0aGUgbGFzdCBicmlnYWRlLCBjbGVhbnVwIHRoZQotICAgICAgICAgICAg ICAgICAgICAgICAgICogYmFja2VuZCBjb25uZWN0aW9uIGZpcnN0IHRvIHByZXZlbnQgdGhl Ci0gICAgICAgICAgICAgICAgICAgICAgICAgKiBiYWNrZW5kIHNlcnZlciBmcm9tIGhhbmdp bmcgYXJvdW5kIHdhaXRpbmcKLSAgICAgICAgICAgICAgICAgICAgICAgICAqIGZvciBhIHNs b3cgY2xpZW50IHRvIGVhdCB0aGVzZSBieXRlcwotICAgICAgICAgICAgICAgICAgICAgICAg ICovCi0gICAgICAgICAgICAgICAgICAgICAgICBiYWNrZW5kLT5jbG9zZSA9IDE7CiAgICAg ICAgICAgICAgICAgICAgICAgICAvKiBzaWduYWwgdGhhdCB3ZSBtdXN0IGxlYXZlICovCiAg ICAgICAgICAgICAgICAgICAgICAgICBmaW5pc2ggPSBUUlVFOwogICAgICAgICAgICAgICAg ICAgICB9CkBAIC0xNTg0LDE4ICsxNTg3LDcgQEAKIGFwcl9zdGF0dXNfdCBhcF9wcm94eV9o dHRwX2NsZWFudXAoY29uc3QgY2hhciAqc2NoZW1lLCByZXF1ZXN0X3JlYyAqciwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJveHlfY29ubl9yZWMgKmJhY2tlbmQp CiB7Ci0gICAgLyogSWYgdGhlcmUgYXJlIG5vIEtlZXBBbGl2ZXMsIG9yIGlmIHRoZSBjb25u ZWN0aW9uIGhhcyBiZWVuIHNpZ25hbGxlZAotICAgICAqIHRvIGNsb3NlLCBjbG9zZSB0aGUg c29ja2V0IGFuZCBjbGVhbiB1cAotICAgICAqLwotCi0gICAgLyogaWYgdGhlIGNvbm5lY3Rp b24gaXMgPCBIVFRQLzEuMSwgb3IgQ29ubmVjdGlvbjogY2xvc2UsCi0gICAgICogd2UgY2xv c2UgdGhlIHNvY2tldCwgb3RoZXJ3aXNlIHdlIGxlYXZlIGl0IG9wZW4gZm9yIEtlZXBBbGl2 ZSBzdXBwb3J0Ci0gICAgICovCi0gICAgaWYgKGJhY2tlbmQtPmNsb3NlIHx8IChyLT5wcm90 b19udW0gPCBIVFRQX1ZFUlNJT04oMSwxKSkpIHsKLSAgICAgICAgYmFja2VuZC0+Y2xvc2Vf b25fcmVjeWNsZSA9IDE7Ci0gICAgICAgIGFwX3NldF9tb2R1bGVfY29uZmlnKHItPmNvbm5l
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
On Feb 14, 2006, at 3:54 PM, Ruediger Pluem wrote: On 02/14/2006 01:51 PM, Jim Jagielski wrote: since it really does help track some things down... In the meantime, if you can send the latest patch, I'll test it here. Please find attached Changes to the previous one: 1. Diff against r377821. 2. I removed the !backend check also. I am curious about the test results. No regressions... On Head: Failed TestStat Wstat Total Fail Failed List of Failed --- t/http11/basicauth.t 31 33.33% 2 t/security/CVE-2004-0811.t84 50.00% 1-4 12 tests and 14 subtests skipped. Failed 2/64 test scripts, 96.88% okay. 5/2478 subtests failed, 99.80% okay. With the patch: Failed TestStat Wstat Total Fail Failed List of Failed --- t/http11/basicauth.t 31 33.33% 2 t/security/CVE-2004-0811.t84 50.00% 1-4 12 tests and 14 subtests skipped. Failed 2/64 test scripts, 96.88% okay. 5/2478 subtests failed, 99.80% okay.
Re: [Patch] Keep Alive not workwing with mod_proxy (PR38602)
On 02/14/2006 10:48 PM, Jim Jagielski wrote: On Feb 14, 2006, at 3:54 PM, Ruediger Pluem wrote: I am curious about the test results. No regressions... Good. Thanks for testing that fast, even on Valentine's Day :). Regards Rüdiger
