Re: mod_python 3.2.8 available for testing
Oops, I've sent this mail a bit too fast... As usual, all three binary versions are available here : http://nicolas.lehuen.com/download/mod_python/ Regards, Nicolas 2006/2/20, Nicolas Lehuen [EMAIL PROTECTED]: +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2
Re: mod_python 3.2.8 available for testing
Hi Oden, The Apache 2.2 support will likely go into the 3.2.9 bugfix release. We just wanted to get the security problem out of the way first. Jim Oden Eriksson wrote: +1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2 Note that I applied this change: http://issues.apache.org/jira/browse/MODPYTHON-78
Re: 3.2.8 summary / core group vote
+1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Re: 3.2.8 summary / core group vote
+1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Re: 3.2.8 summary / core group vote
+1 core vote Nicolas Lehuen wrote .. +1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Re: 3.2.8 summary / core group vote
Hi Michel, I've tested your patch on Win32 + Apache 2.2 and it mostly works (compilation + unit tests) - except for the changes in the PSP lexer parser. They now includ unistd.h which was previously hidden for Win32 platforms.It looks like you have generated those files from the .l grammar using flex, maybe it was an old version ? In any case, I don't understand what those changes have to do with the problem you reported. So my position would be to integrate your patch except for the PSP part. Regards, Nicolas 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: Hi Michel, Please create a JIRA issue. We are much less likely to loose track of it if it's in the issue tracker. Thanks, Jim Michel Jouvin wrote: 0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1 I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. I reported this a couple of months ago during 3.2 beta. Do you want me to resubmit this problem via JIRA ? Or just to resend the required fixes ? Cheers, Michel --On lundi 20 février 2006 16:18 -0500 Graham Dumpleton [EMAIL PROTECTED] wrote: +1 core vote Nicolas Lehuen wrote .. +1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5 * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
Re: 3.2.8 summary / core group vote
Er... I should say that the changes in _pspmodule.c are fine, so they should be integrated. The problems are in the changes brought to the files that are generated by flex. First, they break on Win32, second, since the .l source file is unchanged, next time flex is run the changes will be overwritten. Regards, Nicolas 2006/2/21, Nicolas Lehuen [EMAIL PROTECTED]: Hi Michel, I've tested your patch on Win32 + Apache 2.2 and it mostly works (compilation + unit tests) - except for the changes in the PSP lexer parser. They now includ unistd.h which was previously hidden for Win32 platforms.It looks like you have generated those files from the .l grammar using flex, maybe it was an old version ? In any case, I don't understand what those changes have to do with the problem you reported. So my position would be to integrate your patch except for the PSP part. Regards, Nicolas 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: Hi Michel, Please create a JIRA issue. We are much less likely to loose track of it if it's in the issue tracker. Thanks, Jim Michel Jouvin wrote: 0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1 I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. I reported this a couple of months ago during 3.2 beta. Do you want me to resubmit this problem via JIRA ? Or just to resend the required fixes ? Cheers, Michel --On lundi 20 février 2006 16:18 -0500 Graham Dumpleton [EMAIL PROTECTED] wrote: +1 core vote Nicolas Lehuen wrote .. +1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5 * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
[RT] what's the roadmap?
Now that we've got a release of libapreq2 out the door, it's a good time to think about the direction of the project going forward. So let's take a look at where we are now, and figure out where we want to be in a year from now, and map out some goals for getting there. Right now we have a handful of active committers, with myself volunteering to play RM; pgollucci has volunteered to improve the website docs, which are priorities now, and randyk supports the win32 platform. Other committers like maxk provide review and oversight, although not for the release tarball this time. This time we got lots of help from httpd'ers, who have expressed an interest in seeing this list absorbed into [EMAIL PROTECTED] I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. Anyways, since we're mapping out goals in this thread I think that should be our long-term one. Getting there would involve moving this list into [EMAIL PROTECTED], and our commit list to [EMAIL PROTECTED]; tackling the automake problem, writing better docs/webpages, improving the maintainability of the codebase. We'd have to stop trying to be an aggregation point for the httpd and mod-perl communities, and instead work more directly within each community. I think people are generally too busy with their respective projects to build this community into a separate TLP, and our scope can stay smaller without trying to be a separate project: we can just be about the Perl and C apis as we have always been. Glue writers for other languages seem to be content with libapreq1 for the most part, and haven't been motivated to contribute directly to the libapreq2 codebase. So what are your thoughts about the future of apreq? -- Joe Schaefer
Re: [RT] what's the roadmap?
I'd love to see libapreq2 in httpd base and the perl glue in mod_perl asap i think it would be best for all three projects. On Feb 20, 2006, at 2:25 PM, Joe Schaefer wrote: Now that we've got a release of libapreq2 out the door, it's a good time to think about the direction of the project going forward. So let's take a look at where we are now, and figure out where we want to be in a year from now, and map out some goals for getting there. Right now we have a handful of active committers, with myself volunteering to play RM; pgollucci has volunteered to improve the website docs, which are priorities now, and randyk supports the win32 platform. Other committers like maxk provide review and oversight, although not for the release tarball this time. This time we got lots of help from httpd'ers, who have expressed an interest in seeing this list absorbed into [EMAIL PROTECTED] I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. Anyways, since we're mapping out goals in this thread I think that should be our long-term one. Getting there would involve moving this list into [EMAIL PROTECTED], and our commit list to [EMAIL PROTECTED]; tackling the automake problem, writing better docs/webpages, improving the maintainability of the codebase. We'd have to stop trying to be an aggregation point for the httpd and mod-perl communities, and instead work more directly within each community. I think people are generally too busy with their respective projects to build this community into a separate TLP, and our scope can stay smaller without trying to be a separate project: we can just be about the Perl and C apis as we have always been. Glue writers for other languages seem to be content with libapreq1 for the most part, and haven't been motivated to contribute directly to the libapreq2 codebase. So what are your thoughts about the future of apreq? -- Joe Schaefer
Re: [RT] what's the roadmap?
Eli Marmor wrote: Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? ++1 and I'd be happy to help review anyone's efforts in this direction. I believe that axing the Perl from the base library may clean the fears of the httpders, while having the C in httpd/apr and having only Perl in the Perl-glue (that depends on a standard stuff which was integrated into httpd/apr) may help the mod_perl guys to integrate it. You know, I know, Joe knows apreq's c core isn't all that perl centric, but I don't think the [EMAIL PROTECTED] community is really aware of this fact. This is a good suggestion. Bill
Re: [RT] what's the roadmap?
Geoffrey Young wrote: I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. From the experiences I have had talking to people on the mod_perl list about mod_perl2, the most common issue for users coming from mod_perl 1 is how to handle the request data other than using $r-args or CGI. I think that having the perl glue install alongside the standard mod_perl libraries would be ideal. IMHO, a sizable chunk of mod_perl first timers are looking to process arguments from a form, which can of course be done with CGI but having native libraries to handle this would be a big win. Make the perl glue libs readily available to the user with a standard mod_perl install.
Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On Wed, Feb 15, 2006 at 04:44:43PM -, Jim Jagielski wrote: Author: jim Date: Wed Feb 15 08:44:42 2006 New Revision: 378032 URL: http://svn.apache.org/viewcvs?rev=378032view=rev Log: *) mod_proxy: Fix KeepAlives not being allowed and set to backend servers. PR38602. [Ruediger Pluem, Jim Jagielski] Also, document previous patch: *) Correctly initialize mod_proxy workers, which use a combination of local and shared datasets. Adjust logging to better trace usage. PR38403. [Jim Jagielski] This one seems to have broken the proxy tests again, failed tests are: t/ssl/proxy.t 172 58 33.72% 3 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 115- 116 118-120 122 124 126 128 130 132 134 136 139-140 143-144 147-148 151-152 155- 156 159-160 163-164 167-168 171-172 if I svn up -r378031 modules/proxy this goes away. This looks like a lot of reverse proxy-to-SSL-backend tests failing with 502 errors due to the proxy failing to negotiate an SSL connection to the backend: [Mon Feb 20 09:27:50 2006] [info] SSL Library Error: 336130315 error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (which is the kind of error you get when you try to negotiate SSL with something which doesn't speak SSL; perhaps the wrong backend is being selected?) joe
AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
-Ursprüngliche Nachricht- Von: Joe Orton New Revision: 378032 URL: http://svn.apache.org/viewcvs?rev=378032view=rev Log: *) mod_proxy: Fix KeepAlives not being allowed and set to backend servers. PR38602. [Ruediger Pluem, Jim Jagielski] Also, document previous patch: *) Correctly initialize mod_proxy workers, which use a combination of local and shared datasets. Adjust logging to better trace usage. PR38403. [Jim Jagielski] This one seems to have broken the proxy tests again, failed tests are: t/ssl/proxy.t 172 58 33.72% 3 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 115- 116 118-120 122 124 126 128 130 132 134 136 139-140 143-144 147-148 151-152 155- 156 159-160 163-164 167-168 171-172 if I svn up -r378031 modules/proxy this goes away. This Hmm. Given http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL PROTECTED] this is really weird. Maybe another change that happened after r378032? Regards Rüdiger
Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On Mon, Feb 20, 2006 at 10:53:27AM +0100, Plüm, Rüdiger, VIS wrote: Von: Joe Orton New Revision: 378032 URL: http://svn.apache.org/viewcvs?rev=378032view=rev Log: *) mod_proxy: Fix KeepAlives not being allowed and set to backend servers. PR38602. [Ruediger Pluem, Jim Jagielski] Also, document previous patch: *) Correctly initialize mod_proxy workers, which use a combination of local and shared datasets. Adjust logging to better trace usage. PR38403. [Jim Jagielski] This one seems to have broken the proxy tests again, failed tests are: ... if I svn up -r378031 modules/proxy this goes away. This Hmm. Given http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL PROTECTED] this is really weird. Maybe another change that happened after r378032? Maybe Jim's build didn't include mod_ssl? r378032 is the most recent change to modules/proxy. joe
Re: mod_python 3.2.8 available for testing
+1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 I used the 3.2.x branch out of SVN rather than the tar ball though. Graham
AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
-Ursprüngliche Nachricht-
Von: Joe Orton
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox
/ajax/[EMAIL PROTECTED]
this is really weird. Maybe another change that happened after r378032?
Maybe Jim's build didn't include mod_ssl? r378032 is the most recent
change to modules/proxy.
Maybe. Got another idea in the meantime. Maybe it is because we use the same
socket to a backend, but we create a new conn_rec each time for this backend
and thus try to reinit the existing ssl connection. Could you please give the
following patch a try?
Index: proxy_util.c
===
--- proxy_util.c(revision 379071)
+++ proxy_util.c(working copy)
@@ -1511,7 +1511,7 @@
return APR_SUCCESS;
/* deterimine if the connection need to be closed */
-if (conn-close_on_recycle || conn-close) {
+if (conn-close_on_recycle || conn-close || conn-is_ssl) {
apr_pool_t *p = conn-pool;
apr_pool_clear(conn-pool);
memset(conn, 0, sizeof(proxy_conn_rec));
It closes a ssl backend connection once it is returned to the connection pool,
such that we have no persistent ssl connections to the backend.
Obviously this is only a workaround.
Regards
Rüdiger
Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On Mon, Feb 20, 2006 at 11:30:02AM +0100, Plüm, Rüdiger, VIS wrote: -Ursprüngliche Nachricht- Von: Joe Orton http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox /ajax/[EMAIL PROTECTED] this is really weird. Maybe another change that happened after r378032? Maybe Jim's build didn't include mod_ssl? r378032 is the most recent change to modules/proxy. Maybe. Got another idea in the meantime. Maybe it is because we use the same socket to a backend, but we create a new conn_rec each time for this backend and thus try to reinit the existing ssl connection. Could you please give the following patch a try? That fixed most of the failures, there are still two left: t/ssl/proxyok 61/172# Failed test 62 in t/ssl/proxy.t at line 112 fail #2 t/ssl/proxyok 112/172# Failed test 113 in /local/httpd/pf-trunk/blib/lib/Apache/TestCommonPost.pm at line 131 fail #102 t/ssl/proxyFAILED tests 62, 113 Failed 2/172 tests, 98.84% okay I found only one pertinent error message in the log: [Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP: connection complete to 127.0.0.1:8529 (localhost.localdomain) [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: pass request body failed to 127.0.0.1:8529 (localhost.localdomain) [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: pass request body failed to 127.0.0.1:8529 (localhost.localdomain) from 127.0.0.1 () ...perhaps a persistent connection being closed by the backend, and the proxy only finding out about this half way through sending a request body? Hard to handle that in the proxy - probably best to just ungracefully terminate the connection to the client in that case, it should then resend appropriately too. joe
AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
-Ursprüngliche Nachricht-
Von: Joe Orton
Could you please give the following patch a try?
That fixed most of the failures, there are still two left:
OK. That gives a better idea what possibly goes wrong.
t/ssl/proxyok 61/172# Failed test 62 in t/ssl/proxy.t at line 112
fail #2
t/ssl/proxyok 112/172# Failed test 113 in
/local/httpd/pf-trunk/blib/lib/Apache/TestCommonPost.pm at
line 131 fail
#102
t/ssl/proxyFAILED tests 62, 113
Failed 2/172 tests, 98.84% okay
I found only one pertinent error message in the log:
[Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP:
connection complete to 127.0.0.1:8529 (localhost.localdomain)
But this is HTTP to the backend isn't it?
[Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy:
pass request
body failed to 127.0.0.1:8529 (localhost.localdomain)
[Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy:
pass request
body failed to 127.0.0.1:8529 (localhost.localdomain) from
127.0.0.1 ()
...perhaps a persistent connection being closed by the
backend, and the
proxy only finding out about this half way through sending a request
Also my guess. See also point 2 in
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL
PROTECTED]
Is it possible to increase the keepalive timeout temporarily for a test run?
This would give a valuable hint?
body? Hard to handle that in the proxy - probably best to just
ungracefully terminate the connection to the client in that case, it
should then resend appropriately too.
Yes, if get into this situation I guess we have no better chance. But that
should already
be the reaction to this kind of situation.
Ok, I see that this is currently not the case (at least not if we fail during
sending the reponse). The following patch should sent
a 502 to the client in such cases and close the connection to the client:
Index: mod_proxy_http.c
===
--- mod_proxy_http.c(revision 379071)
+++ mod_proxy_http.c(working copy)
@@ -1711,8 +1711,17 @@
cleanup:
if (backend) {
-if (status != OK)
+if (status != OK) {
backend-close = 1;
+if (!r-eos_sent) {
+apr_bucket_brigade *bb;
+
+bb = apr_brigade_create(p, c-bucket_alloc);
+ap_proxy_backend_broke(r, bb);
+ap_pass_brigade(r-output_filters, bb);
+apr_brigade_destroy(bb);
+}
+}
ap_proxy_http_cleanup(proxy_function, r, backend);
}
return status;
But I had the idea to use a possible keepalive header feedback from the
backend to get a feeling at which point of time the backend will close
the connection
Regards
Rüdiger
Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On Mon, Feb 20, 2006 at 12:52:31PM +0100, Plüm, Rüdiger, VIS wrote: I found only one pertinent error message in the log: [Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP: connection complete to 127.0.0.1:8529 (localhost.localdomain) But this is HTTP to the backend isn't it? Yup - this test covers both http/ssl to the backend with http/ssl to the client, omitting the http-http case. [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: pass request body failed to 127.0.0.1:8529 (localhost.localdomain) [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: pass request body failed to 127.0.0.1:8529 (localhost.localdomain) from 127.0.0.1 () ...perhaps a persistent connection being closed by the backend, and the proxy only finding out about this half way through sending a request Also my guess. See also point 2 in http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL PROTECTED] Is it possible to increase the keepalive timeout temporarily for a test run? This would give a valuable hint? Yup, that fixes the failures, though the test is hanging for a while in the two places it was failing before. There are a *lot* of these weird 408 (HTTP_REQUEST_TIME_OUT) errors in the access_log, I notice - it looks like these were happening even before the proxy changes: 127.0.0.1 - - [20/Feb/2006:13:17:44 +] - 408 223 127.0.0.1 - - [20/Feb/2006:13:17:45 +] POST /eat_post HTTP/1.1 200 6 127.0.0.1 - - [20/Feb/2006:13:17:45 +] POST /eat_post HTTP/1.0 200 6 127.0.0.1 - - [20/Feb/2006:13:17:45 +] - 408 223 that code is only generated new request parsing code. Brian? body? Hard to handle that in the proxy - probably best to just ungracefully terminate the connection to the client in that case, it should then resend appropriately too. Yes, if get into this situation I guess we have no better chance. But that should already be the reaction to this kind of situation. Ok, I see that this is currently not the case (at least not if we fail during sending the reponse). The following patch should sent a 502 to the client in such cases and close the connection to the client: That's not what I meant. This is a bit tricky. Here's a restatement of the problem, just to make sure we're talking about the same thing: If a client reuses a connection to an HTTP server which has been held open persistently, there is a risk that the connection may be closed either beforehand or simultaneously to when the client tries to reuse it. So, it's quite normal to start sending a POST request with a body, and then half way through sending the request body, you get an TCP RST or a FIN. HTTP/1.1 clients have logic to open a new connection and resend the request if that happens. If the client in this case is the proxy, then the proxy may not be able to resend the whole request body if it is streaming it through and may already have discarded the first half by the time it sees the RST/FIN/. If the proxy has the correct logic then this can be handled correctly. In handling a request which includes a body (and the body will not/cannot be cached entirely in memory): a) if the connection to the client has been kept open persistently (i.e. r-connection-keepalives 1), then it is safe to forward the request on a connection to the backend which has itself been held open persistently. If the backend connection is closed whilst sending the request/body, then the connection to the client should also immediately be closed without sending a response. b) if the connection to the client has *not* been kept open persistently, then it is only safe to forward a request which includes a request body on a newly opened connection to the backend. (since such a connection is not vulnerable to a persistent connection timeout) Does that make sense? Regards, joe
Re: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Hmmm... Possibly SSL requires close_on_recycle. Or, at least, using that flag as required for SSL.
3.2.8 summary / core group vote
Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Re: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Small idea: should we adjust ap_proxy_http_cleanup() to accept a status value, and thus make that logic internal to it? That is, have an OK/NOK conditional aspect to ap_proxy_http_cleanup()? I think it would be useful at the other places were we use it... PS: I'm planning to be offline for the rest of the day to try to enjoy the holiday :)
Re: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Jim Jagielski wrote: Hmmm... Possibly SSL requires close_on_recycle. Or, at least, using that flag as required for SSL. I don't have time to explain in more detail, but the more I look over the old way, it was to maintain some sort of local state-of-health on the socket pre-and-post each request... As such, I'm *thinking* that the code patch should be reverted to maintain that logic, and extend it, rather than remove it... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
-Ursprüngliche Nachricht- Von: Jim Jagielski Jim Jagielski wrote: Hmmm... Possibly SSL requires close_on_recycle. Or, at least, using that flag as required for SSL. I don't have time to explain in more detail, but the more I look over the old way, it was to maintain some sort of local state-of-health on the socket pre-and-post each request... As such, I'm *thinking* that the code patch should be reverted to maintain that logic, and extend it, rather than remove it... I think the SSL problem is caused by throwing away the conn_rec entry for the backend and create a new one for each request. That does not sound right, but I admit that keeping it must be carefully examinated due to several possible issues. Two that I can see immeditately are: 1. memory pools 2. filters For me that puts the question on the table if using fake request_rec and conn_rec structures for the backend connections is really a good idea. This misuse already leads to problems in other areas. But reworking this will take much time and work and is only mid to long term. Might be easier if we have a http / https client library as part of httpd or apr-util. The other problem Joe mentioned is a problem that I feared. See 2. in http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL PROTECTED] I also need to think about Joes ideas in more detail before responding to them. They might be a good solution to this. Regarding revert. The old version is really bad for performance. So I would like to keep the patch, provided that we can fix the regressions within a short timeframe (fixes do not need to provide optimal perfomance , so non persistance for ssl backend connections would be ok for me as a fix in this context). If not I would propose to revert on trunk and create a branch to work this out. Regards Rüdiger
Serf, WAS: Re: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Plüm wrote: I think the SSL problem is caused by throwing away the conn_rec entry for the backend and create a new one for each request. That does not sound right, but I admit that keeping it must be carefully examinated due to several possible issues. Two that I can see immeditately are: 1. memory pools 2. filters For me that puts the question on the table if using fake request_rec and conn_rec structures for the backend connections is really a good idea. This misuse already leads to problems in other areas. But reworking this will take much time and work and is only mid to long term. Might be easier if we have a http / https client library as part of httpd or apr-util. Something like this maybe: http://svn.webdav.org/repos/projects/serf/trunk/ It started out to become apr-serf, made a jump to the short-lived Commons, and ended up at webdav.org. There is a current effort by Justin Erenkrantz to get Serf completed, or at least complete enough to complete ra_serf, a Subversion remote access library. I expect that with a couple of months the churn is gone, and its API stable enough to use here in HTTP Server land. Sander
Re: mod_python 3.2.8 available for testing
+1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2 Note that I applied this change: http://issues.apache.org/jira/browse/MODPYTHON-78 -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
AW: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
-Ursprüngliche Nachricht- Von: Jim Jagielski term. Might be easier if we have a http / https client library as part of httpd or apr-util. This only helps http, not ajp/fcgi or other protocols. True, but ajp already does not use the fake conn_rec / request_rec stuff. Instead it works directly on the socket, or better the code in ajp* works directly on the socket and mod_proxy_ajp calls high level functions from these files. Currently I have no idea about fcgi. Regards Rüdiger
Re: AW: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski=20 term. Might be easier if we have a http / https client=20 library as part=20 of httpd or apr-util. =20 This only helps http, not ajp/fcgi or other protocols. True, but ajp already does not use the fake conn_rec / request_rec = stuff. Instead it works directly on the socket, or better the code in ajp* = works directly on the socket and mod_proxy_ajp calls high level functions from these files. Currently I have no idea about fcgi. I was just thinking that having mod_proxy provide some sort of abstraction for these might be best in the long run... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: AW: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 02/20/2006 06:38 PM, Jim Jagielski wrote: =20 This only helps http, not ajp/fcgi or other protocols. True, but ajp already does not use the fake conn_rec / request_rec = stuff. Instead it works directly on the socket, or better the code in ajp* = works directly on the socket and mod_proxy_ajp calls high level functions from these files. Currently I have no idea about fcgi. I was just thinking that having mod_proxy provide some sort of abstraction for these might be best in the long run... Ok, my mistake, I did not understand it this way :-). Seems reasonable. SSL support on this layer would be a nice feature, so that we only have to worry about the higher level protocols in the mod_proxy_* modules. Regards Rüdiger
Re: [RT] what's the roadmap?
Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? I believe that axing the Perl from the base library may clean the fears of the httpders, while having the C in httpd/apr and having only Perl in the Perl-glue (that depends on a standard stuff which was integrated into httpd/apr) may help the mod_perl guys to integrate it. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 02/20/2006 05:17 PM, Plüm wrote: For me that puts the question on the table if using fake request_rec and conn_rec structures for the backend connections is really a good idea. This misuse already leads to problems in other areas. Of course I should point a reference :-): http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox/[EMAIL PROTECTED] Regards Rüdiger
Re: [RT] what's the roadmap?
I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. --Geoff
Re: 3.2.8 summary / core group vote
0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1 I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. I reported this a couple of months ago during 3.2 beta. Do you want me to resubmit this problem via JIRA ? Or just to resend the required fixes ? Cheers, Michel --On lundi 20 février 2006 16:18 -0500 Graham Dumpleton [EMAIL PROTECTED] wrote: +1 core vote Nicolas Lehuen wrote .. +1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5 * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 02/20/2006 02:51 PM, Joe Orton wrote: That's not what I meant. This is a bit tricky. Here's a restatement of the problem, just to make sure we're talking about the same thing: If a client reuses a connection to an HTTP server which has been held open persistently, there is a risk that the connection may be closed either beforehand or simultaneously to when the client tries to reuse it. So, it's quite normal to start sending a POST request with a body, and then half way through sending the request body, you get an TCP RST or a FIN. HTTP/1.1 clients have logic to open a new connection and resend the request if that happens. Do you have any examples for such clients? All common browsers? If the client in this case is the proxy, then the proxy may not be able to resend the whole request body if it is streaming it through and may already have discarded the first half by the time it sees the RST/FIN/. If the proxy has the correct logic then this can be handled correctly. In handling a request which includes a body (and the body will not/cannot be cached entirely in memory): Thanks for explanation. Now I understand what you mean a) if the connection to the client has been kept open persistently (i.e. r-connection-keepalives 1), then it is safe to forward the request on a connection to the backend which has itself been held open persistently. If the backend connection is closed whilst sending the request/body, then the connection to the client should also immediately be closed without sending a response. Ok. Possibly tricky to implement. From my first view it would require the ap_http_header_filter to be removed, r-connection-keepalive set to AP_CONN_CLOSE and an eos sent down the chain, but I am neither sure that this is 1. RFC compliant 2. Good code b) if the connection to the client has *not* been kept open persistently, then it is only safe to forward a request which includes a request body on a newly opened connection to the backend. (since such a connection is not vulnerable to a persistent connection timeout) In principle we know too late if the request contains a body or not (checked in ap_proxy_http_request, but we would need to know in ap_proxy_connect_backend). We could check for C-L or T-E in headers_in as a marker for a possible request body. But this could be used by evil / bad clients to close pooled backend connections without actually sending a request body. Or is this assumption to paranoid? Regards Rüdiger
Re: 3.2.8 summary / core group vote
Hi Michel, Please create a JIRA issue. We are much less likely to loose track of it if it's in the issue tracker. Thanks, Jim Michel Jouvin wrote: 0 Tru64 5.1B-3, Apache 2.0.55, worker MPM, Python 2.4.1 I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. I reported this a couple of months ago during 3.2 beta. Do you want me to resubmit this problem via JIRA ? Or just to resend the required fixes ? Cheers, Michel --On lundi 20 février 2006 16:18 -0500 Graham Dumpleton [EMAIL PROTECTED] wrote: +1 core vote Nicolas Lehuen wrote .. +1 core vote 2006/2/20, Jim Gallacher [EMAIL PROTECTED]: +1 core vote Jim Gregory (Grisha) Trubetskoy wrote: Based on summary below, +1 from for putting it out there. Grisha Graham Dumpleton [EMAIL PROTECTED] +1 Mac OS X 10.4, apache 2.0.55 mpm-worker, python 2.3.5 (3.2.x SVN trunk) Nicolas Lehuen [EMAIL PROTECTED] +1 mod_python 3.2.8 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 Barry Pederson [EMAIL PROTECTED] +1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2 Jim Gallacher [EMAIL PROTECTED] +1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5 * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
Re: shutdown and linux poll()
Hi --
I've crafted what seems to me like a reasonably minimal set of
patches to deal with the issue I described in this thread:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=113986864730305w=2
The crux of the problem is that on Linux, when using httpd with
the worker MPM (and probably the event MPM too), hard restarts and
shutdowns often end up sending SIGKILL to httpd child processes
because those processes are waiting for their worker threads to
finish polling on Keep-Alive connections.
Apparently, on most OSes, if one thread closes a socket descriptor
then other threads polling on it immediately get a return value.
This certainly seems to be the case on Solaris. But on Linux,
worker threads polling on their sockets in apr_wait_for_io_or_timeout()
don't get an error return value until the full (usually 15 second)
Keep-Alive timeout period is up. The main httpd process deems that
too long, and issues SIGKILL to the child processes.
For me personally, the consequence is that all my nice cleanup
handlers registered against the memory pool that's passed during the
child_init stage never get called. This is particularly painful
if one is hoping to, for example, cleanly shut down DB connections
that one has opened with mod_dbd/apr_dbd. In the case of mod_dbd,
it opens its reslist of apr_dbd connections against the pool
passed in the child_init stage, which with the worker MPM is its
pchild pool. When SIGKILL is applied, the apr_pool_destroy(pchild)
call is often not reached, so DB disconnections don't occur;
even if I'm trying to shut down httpd in a hurry, I don't really
want that to happen if at all possible.
Without further ado, then, my initial patches. These are
Unix-only at the moment; I have little experience with other OSes.
If anyone wants to propose something better, and/or suggest
changes, that would be superb. In the meantime, since these
work for me, I'll start applying them against APR and httpd for
my own use.
First, the APR patches (against trunk):
===
--- include/apr_network_io.h.orig 2006-02-20 16:20:44.841609000
-0500
+++ include/apr_network_io.h2006-02-20 16:24:19.99359 -0500
@@ -99,6 +99,7 @@
* until data is available.
* @see apr_socket_accept_filter
*/
+#define APR_INTERRUPT_WAIT 65536 /** Return from IO wait on interrupt
*/
/** @} */
--- network_io/unix/sockopt.c.orig 2006-02-17 11:24:13.058691778 -0500
+++ network_io/unix/sockopt.c 2006-02-17 11:28:08.910410867 -0500
@@ -318,6 +318,9 @@
return APR_ENOTIMPL;
#endif
break;
+case APR_INTERRUPT_WAIT:
+apr_set_option(sock, APR_INTERRUPT_WAIT, on);
+break;
default:
return APR_EINVAL;
}
--- support/unix/waitio.c.orig 2005-07-09 03:07:17.0 -0400
+++ support/unix/waitio.c 2006-02-17 11:23:42.620856949 -0500
@@ -49,7 +49,8 @@
do {
rc = poll(pfd, 1, timeout);
-} while (rc == -1 errno == EINTR);
+} while (rc == -1 errno == EINTR
+ (f || !apr_is_option_set(s, APR_INTERRUPT_WAIT)));
if (rc == 0) {
return APR_TIMEUP;
}
===
Second, the httpd patches (also against trunk):
===
--- server/mpm/worker/worker.c.orig 2006-02-20 16:26:55.302701000 -0500
+++ server/mpm/worker/worker.c 2006-02-20 16:46:44.764980568 -0500
@@ -213,6 +213,19 @@
*/
#define LISTENER_SIGNAL SIGHUP
+/* The WORKER_SIGNAL signal will be sent from the main thread to the
+ * worker threads after APR_INTERRUPT_WAIT is set true on their sockets.
+ * This ensures that on systems (i.e., Linux) where closing the worker
+ * socket doesn't awake the worker thread when it is polling on the socket
+ * (especially after in apr_wait_for_io_or_timeout() when handling
+ * Keep-Alive connections), close_worker_sockets() and join_workers()
+ * still function in timely manner and allow ungraceful shutdowns to
+ * proceed to completion. Otherwise join_workers() doesn't return
+ * before the main process decides the child process is non-responsive
+ * and sends a SIGKILL.
+ */
+#define WORKER_SIGNAL AP_SIG_GRACEFUL
+
/* An array of socket descriptors in use by each thread used to
* perform a non-graceful (forced) shutdown of the server. */
static apr_socket_t **worker_sockets;
@@ -222,6 +235,7 @@
int i;
for (i = 0; i ap_threads_per_child; i++) {
if (worker_sockets[i]) {
+apr_socket_opt_set(worker_sockets[i], APR_INTERRUPT_WAIT, 1);
apr_socket_close(worker_sockets[i]);
worker_sockets[i] = NULL;
}
@@ -822,6 +836,11 @@
ap_scoreboard_image-servers[process_slot][thread_slot].generation
= ap_my_generation;
ap_update_child_status_from_indexes(process_slot, thread_slot,
SERVER_STARTING,
Re: svn commit: r378394 - /httpd/httpd/trunk/modules/aaa/mod_auth.h
On 2/18/2006 at 4:59 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Ruediger Pluem wrote: On 02/18/2006 11:46 PM, David Reid wrote: Ruediger Pluem wrote: So please revert or fix. Why are people so quick to ask for reversion these days? Please note that I said revert *or* fix. I fully understand (not in technical detail) the trouble you have with the reworked parts of the auth system. Although I know that this is not required, I like to see the trunk at least compilable without further patches to continue other work on it. I also appreciate your work on cleaning out the bugs and problems on the reworked auth code, but if this takes commits that make the code somewhat uncompilable please open a branch and merge it once your work is finished. I think this would satisfy everybody's needs. Nothing personal, just that people seem mmore willing to shout revert than to look and fix it. You did do that - so apologies if it sounded like I was having a go. :-) My biggest complaint is the lack of documentation or attempt at documentation of the revised config. I'm more than willing to try the new code and new config options, but if I can't find anything that tells me how to make the change it's hard. Auth config has never been the easiest thing in the first place. It seems that every time about how to make the changes I ask I'm just told to use the compat module. Are people trying to move things along or not? Well I tried, (http://marc.theaimsgroup.com/?l=apache-httpd-devm=113659184312078w=2) , as well as trying to get all of the documentation for the directives and how-to up to date. In fact all of this work was completed on the authz-dev branch before being merged into trunk. If you read through this message thread you will see that there were a number of things that changed that should ultimately make auth easier to configure. The problem that we have now is transition. There is the old way of doing auth and there is the new way of doing auth. If you want to use the old way or you want to mix them, then you have to use mod_access_compat. There were also a few APIs that became obsolete or reclassified as optional . ap_requires() - Removed. Reason: No longer needed in the provider based model since all 'Require' args are stored per-provider and not as a single array. ap_auth_type(), ap_auth_name(), ap_some_auth_required() - Reclassified optional. Reason: The implementation of these functions was moved to the authn or authz core modules where it belongs rather than in httpd core. The APIs that continue to exist in httpd core attempt to call the optional functions if available or return NULL of not. ap_satisfies() - Obsolete. Reason: The 'Satisfy' directive has been deprecated and the implementation has been moved to mod_access_compat. It is expected to be removed completely in Apache 3.0. Since ap_satisfies() is obsolete, I did not provide a stub function in core as was done with ap_auth_type(), ap_auth_name() and ap_some_auth_required(). The reasoning behind this decision was because ap_satisfies() has an expected end of life while the other APIs do not. Therefore all modules going forward should be reworked to eliminate the need for ap_satisfies(). However, to support backwards compatibility until mod_access_compat is removed in Apache 3.0, the optional function has been provided. Out of convenience I could implement a stub function in core which would attempt to call the ap_satisfies() optional function if mod_access_compat has been loaded. But this seems much more dangerous than forcing the module to import the function and making sure that it can handle the NULL return if mod_access_compat has not been loaded. Brad
Re: [RT] what's the roadmap?
Eli Marmor [EMAIL PROTECTED] writes: Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), What makes the most sense to me is to somehow integrate trunk/include, trunk/library and trunk/module into httpd. For instance, I'd like to see an fcgi module grow up alongside trunk/module/apache2. I think splitting the library off into apr makes little sense from a user's standpoint, since the whole point of it is to parse server-side form submissions. and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? Either directly into mod_perl, or as a standalone release from the perl pmc would be cool with me. -- Joe Schaefer
[jira] Created: (MODPYTHON-138) Python.h should be included first
Python.h should be included first - Key: MODPYTHON-138 URL: http://issues.apache.org/jira/browse/MODPYTHON-138 Project: mod_python Type: Bug Components: core Versions: 3.2 Environment: Tru64 5.1B, Python 2.4.1, Apache 2..55 Reporter: Michel Jouvin I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. This change should have no impact on platforms where the current include order works. Affected files are : src/include/psp_parser.h src/include/mod_python.h src/include/psp_flex.h src/include/mod_python.h.in src/_pspmodule.c src/psp_parser.c I have a patch file available, I'll try to attach it to this issue if I manage to find how to do it... Michel -- 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: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 02/20/2006 11:50 AM, Joe Orton wrote: Maybe. Got another idea in the meantime. Maybe it is because we use the same socket to a backend, but we create a new conn_rec each time for this backend and thus try to reinit the existing ssl connection. Could you please give the following patch a try? Meanwhile I committed a better version of the patch as r379237. http://svn.apache.org/viewcvs?rev=379237view=rev If you have some cycles left could you please test? (I know that I should really get the test framework running on my box. First thing on my TODO list) That fixed most of the failures, there are still two left: Regards Rüdiger
[jira] Updated: (MODPYTHON-138) Python.h should be included first
[ http://issues.apache.org/jira/browse/MODPYTHON-138?page=all ] Michel Jouvin updated MODPYTHON-138: Attachment: mod_python-3.2.6-tru64.patch Diff file containing changes implemented to fix the issue described. Built for 3.2.6 but should probably works with any 3.2.x. Python.h should be included first - Key: MODPYTHON-138 URL: http://issues.apache.org/jira/browse/MODPYTHON-138 Project: mod_python Type: Bug Components: core Versions: 3.2 Environment: Tru64 5.1B, Python 2.4.1, Apache 2..55 Reporter: Michel Jouvin Attachments: mod_python-3.2.6-tru64.patch I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. This change should have no impact on platforms where the current include order works. Affected files are : src/include/psp_parser.h src/include/mod_python.h src/include/psp_flex.h src/include/mod_python.h.in src/_pspmodule.c src/psp_parser.c I have a patch file available, I'll try to attach it to this issue if I manage to find how to do it... Michel -- 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: svn commit: r379237 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
[EMAIL PROTECTED] wrote: @@ -1672,6 +1672,14 @@ backend-is_ssl = is_ssl; +/* + * TODO: Currently we cannot handle persistent SSL backend connections, + * because we recreate backend-connection for each request and thus + * try to initialize an already existing SSL connection. This does + * not work. + */ +if (is_ssl) +backend-close_on_recycle = 1; +1 for leveraging close_on_recycle ! :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: Serf, WAS: Re: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 2/20/06, Sander Striker [EMAIL PROTECTED] wrote: For me that puts the question on the table if using fake request_rec and conn_rec structures for the backend connections is really a good idea. This misuse already leads to problems in other areas. But reworking this will take much time and work and is only mid to long term. Might be easier if we have a http / https client library as part of httpd or apr-util. Something like this maybe: http://svn.webdav.org/repos/projects/serf/trunk/ It started out to become apr-serf, made a jump to the short-lived Commons, and ended up at webdav.org. There is a current effort by Justin Erenkrantz to get Serf completed, or at least complete enough to complete ra_serf, a Subversion remote access library. I expect that with a couple of months the churn is gone, and its API stable enough to use here in HTTP Server land. Yup. I'm currently 'sponsored' by Google to produce ra_serf - so that's my short-term focus. If you don't follow [EMAIL PROTECTED], ra_serf + Serf can now do a checkout from a mod_dav_svn setup: http://svn.haxx.se/dev/archive-2006-02/1025.shtml Long-term, Greg and I and others who contributed to the early days of Serf have always left open the possibility of closing the cycle with httpd - both as for a replacement for mod_proxy's client code and as another (ideally more efficient) design to do filters across httpd. However, that's not in scope for me to do in the next few months. Serf's mailing list is at: http://mailman.webdav.org/mailman/listinfo/serf-dev/ (You'll find some familiar faces posting there. *duck*) Enjoy. -- justin
Re: mod_python license
On 2/19/06, Jim Gallacher [EMAIL PROTECTED] wrote: I just notice that a few files still say that mod_python uses Apache License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this is an error and that *everything* should be version 2.0? Yes. -- justin
