PR42829: graceful restart with multiple listeners using prefork MPM can result in hung processes
Hi, this bug can be quite annoying because of the resources used by the hung processes. It happens e.g. under Linux when epoll is used. The patch from http://issues.apache.org/bugzilla/show_bug.cgi?id=42829#c14 has been in Debian unstable/Ubuntu hardy for several weeks and there have not been any complaints. It would be nice if you could look at it and commit it to svn. Thanks, Stefan
httpd trunk - How to get info that ap_requires used to return
Folks, I want to build mod_perl 2 against httpd trunk but I've encountered a few road-blocks. The one that has held me up recently is to do with the removal of ap_requires from the httpd source sometime since httpd 2.2.6. The mod_perl test suite includes several tests that rely on ap_requires to dig out Require data e.g Require user shaun Require group sheep These obviously now fail when mp is built against the httpd trunk. Presumably there are other straightforward ways to get at the Require configuration for a given directory? I have had a scout round - the mod_authz code uses the require_line data structure but I can't immediately see how this can be related to mod_perl. Thanks, Rolf
Re: httpd trunk - How to get info that ap_requires used to return
On 1/4/2008 at 10:12 AM, in message [EMAIL PROTECTED], Rolf Banting [EMAIL PROTECTED] wrote: Folks, I want to build mod_perl 2 against httpd trunk but I've encountered a few road-blocks. The one that has held me up recently is to do with the removal of ap_requires from the httpd source sometime since httpd 2.2.6. The mod_perl test suite includes several tests that rely on ap_requires to dig out Require data e.g Require user shaun Require group sheep These obviously now fail when mp is built against the httpd trunk. Presumably there are other straightforward ways to get at the Require configuration for a given directory? I have had a scout round - the mod_authz code uses the require_line data structure but I can't immediately see how this can be related to mod_perl. Thanks, Rolf Well, I'm not sure you are going to like the answer. The authz functionality has been completely rearchitected in httpd trunk. Rather than being hooked based which required every authz module in the chain to evaluate all of the require statements, it is now provider based. Basically what this means is that an authz module simply registers the authz types that it supports and then the provider for that authz type is only called when needed. In addition to being provider based, a new logic concept has been added to allow the user to combine different authz types using simple logic groupings. In this architecture, the functionality that ap_requires() performed, no longer makes. The 'Require' statement(s) within a Directory block is no longer just a single authz type or list of types, the authz result must be evaluated within the logical context in which it exists. Under the old architecture, ap_requires() returned a simply list of authz types. In the new architecture, the authz types that are included in a Directory block are no longer a list, but rather a logic tree. Since I don't know how the perl test suite works, I couldn't really tell you how the suite must be rearchitected to fit the new model. I vaguely remember having this discussion with somebody a year or more ago. You might want to check the list archive. Other than that, we would just have to discuss what the test suite is doing and how it might be reworked. Brad
Re: httpd trunk - How to get info that ap_requires used to return
Brad Nicholes wrote: Since I don't know how the perl test suite works, I couldn't really tell you how the suite must be rearchitected to fit the new model. I vaguely remember having this discussion with somebody a year or more ago. You might want to check the list archive. Other than that, we would just have to discuss what the test suite is doing and how it might be reworked. How about a pointer to the patch applied to a prior module or two which replaces ap_requires with the new logic? It's not the framework - it's modperl itself I believe that is the prime issue. The new interfaces need to be built. Bill
Re: Transcoding module for libxml2-based filters
Am Dienstag, den 25.12.2007, 22:54 + schrieb Nick Kew: As developer or co-developer of several libxml2-based filter modules, ... Hey, I thought you were on the expat side :) The basic features are: 1. Sniff charset of incoming data, from (in order): (a) HTTP headers, if available (b) XML BOM / XML Declaration (c) HTML meta elements (d) Configuration default A configuration Like XML2EncSniff HTTP XML META CONF might be desirable for this in the long run. So one can for example ignore META. 2. If the charset is not supported by libxml2, convert it to UTF-8 using apr_xlate (if supported). 3. Remove meta elements that are invalidated by any such conversion. 4. Perform other preprocessing fixups, and offer an optional hook for preprocessing. This means e.g. fix XML decl. if the header tells different? 5. Support post-filtering from UTF-8 to a server admin's choice of charset. Good. The challenging aspect of this is to enable it to be inserted twice in a filter chain (before and after libxml2), and perform different transformations each time. This means two different filter functions, right? Currently it offers configuration options appropriate to a pre-filter, and will export a function for other filter modules to insert it with their own configuration options (f-ctx) for post-filtering. Unless anyone has a better suggestion. Why do you think it is necessary to ask other filters for configuration this way? What is the advantage of this above simply having configuration options for the post filter? Hey, you may want to interface with mod_negotiate :) Charsets are not really negotiable now, but with your module they will we. Sincerely, Joachim
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 4, 2008 12:00 PM, Jim Jagielski [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/dist/ +1 for 2.2.7. Tested on Mac OS 10.5.1 (aka 9.1.0) with APR/APR-util 1.2.12. Some caveats though on Mac OS - I have a hunch they are more about the test suite than anything else. Configure options: ./configure --enable-modules=most --enable-ssl --enable-cache --enable-proxy --enable-disk-cache With httpd-test, the built-in Perl distro yields these failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/security/CVE-2005-2700.t21 50.00% 1 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t 33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/proxy.t 172 113 65.70% 60-172 t/ssl/require.t 52 40.00% 2 5 t/ssl/v2.t11 100.00% 1 t/ssl/varlookup.t72 72 100.00% 1-72 t/ssl/verify.t31 33.33% 2 8 tests and 18 subtests skipped. Failed 13/80 test scripts, 83.75% okay. 234/2824 subtests failed, 91.71% okay. [ error] error running tests (please examine t/logs/error_log) Looking deeper, I replaced Perl with current MacPort perl install and I now get: (The key bit seems it upgrades libwww-perl/5.805 to libwww-perl/5.808.) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 30 15 50.00% 16-30 t/ssl/extlookup.t22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 8 tests and 18 subtests skipped. Failed 9/80 test scripts, 88.75% okay. 108/2824 subtests failed, 96.18% okay. [ error] error running tests (please examine t/logs/error_log) Looking at the error and access logs, httpd is returning success and failures where appropriate, but LWP is somehow dying. So, I'll cast my +1 even with these SSL failures as merely changing the LWP version made some of these go away. If someone wants to dig more and see what's up, that'd be appreciated too...but I wouldn't block the release on this. -- justin
Re: Transcoding module for libxml2-based filters
On Fri, 04 Jan 2008 22:47:16 +0100 Joachim Zobel [EMAIL PROTECTED] wrote: Am Dienstag, den 25.12.2007, 22:54 + schrieb Nick Kew: As developer or co-developer of several libxml2-based filter modules, ... Hey, I thought you were on the expat side :) Just mod_xmlns. All my other SAX parsing modules are libxml2. The basic features are: 1. Sniff charset of incoming data, from (in order): (a) HTTP headers, if available (b) XML BOM / XML Declaration (c) HTML meta elements (d) Configuration default A configuration Like XML2EncSniff HTTP XML META CONF might be desirable for this in the long run. So one can for example ignore META. Indeed, that's a thought. Not to mention sniffing according to Content-Type, since one purpose of this is *also* to support non-markup text. 2. If the charset is not supported by libxml2, convert it to UTF-8 using apr_xlate (if supported). 3. Remove meta elements that are invalidated by any such conversion. 4. Perform other preprocessing fixups, and offer an optional hook for preprocessing. This means e.g. fix XML decl. if the header tells different? Yes, though that's a TBD. 5. Support post-filtering from UTF-8 to a server admin's choice of charset. Good. The challenging aspect of this is to enable it to be inserted twice in a filter chain (before and after libxml2), and perform different transformations each time. This means two different filter functions, right? No, one function, with its behaviour determined by its ctx. Currently it offers configuration options appropriate to a pre-filter, and will export a function for other filter modules to insert it with their own configuration options (f-ctx) for post-filtering. Unless anyone has a better suggestion. Why do you think it is necessary to ask other filters for configuration this way? What is the advantage of this above simply having configuration options for the post filter? That gets messy, with two filters both of AP_FTYPE_RESOURCE. If I hack it with offsets, that breaks interaction with other filters. Hey, you may want to interface with mod_negotiate :) Charsets are not really negotiable now, but with your module they will we. Hehe. Well, there's also mod_charset_lite:-) Thanks for the comments. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Jorge Schrauwen wrote: I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Next time, try out the MS SDK beta and give them a bug report before it's too late :) Not APR to blame, it's the MS SDK headers. http://issues.apache.org/bugzilla/show_bug.cgi?id=40398 is the trivial fix for their bogosity. Bill
Re: Transcoding module for libxml2-based filters
Am Freitag, den 04.01.2008, 22:06 + schrieb Nick Kew: This means two different filter functions, right? No, one function, with its behaviour determined by its ctx. Sure? IMHO two functions that call the same infrastructure function might be clearer. But YMMV, I am an enemy of state. [...] Why do you think it is necessary to ask other filters for configuration this way? What is the advantage of this above simply having configuration options for the post filter? That gets messy, with two filters both of AP_FTYPE_RESOURCE. If I hack it with offsets, that breaks interaction with other filters. H. Maybe this is because I always would configure my filter chain explititely. But everybody using your module will also have to configure his filter chain explicitely, simply because he wants your pre filter to run before his own AP_FTYPE_RESOURCE filter. AddOutputFilter xml2enc-pre;user-filter;xml2enc-post or AddOutputFilter xml2enc-pre;sax;i18n;xml2enc-post or AddOutputFilter xml2enc-pre;sax;htmlplus;i18n;xml2enc-post OK, messy has its point here. Sincerely, Joachim
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Error 2 error C2224: left of '.gsr_interface' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 171 apr Error 3 error C2224: left of '.gsr_group' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 4 error C2224: left of '.gsr_group' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 5 error C2168: 'memcpy' : too few actual parameters for intrinsic function s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 172 apr Error 6 error C2224: left of '.gsr_source' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 173 apr Error 7 error C2224: left of '.gsr_source' must have struct/union types:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 173 apr --- Anybody else seeing this? wrowe? On Jan 4, 2008 11:03 PM, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Jan 4, 2008 12:00 PM, Jim Jagielski [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/dist/ +1 for 2.2.7. Tested on Mac OS 10.5.1 (aka 9.1.0) with APR/APR-util 1.2.12. Some caveats though on Mac OS - I have a hunch they are more about the test suite than anything else. Configure options: ./configure --enable-modules=most --enable-ssl --enable-cache --enable-proxy --enable-disk-cache With httpd-test, the built-in Perl distro yields these failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/security/CVE-2005-2700.t21 50.00% 1 t/ssl/basicauth.t 32 66.67% 2-3 t/ssl/env.t 30 23 76.67% 1-8 16-30 t/ssl/extlookup.t 22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/headers.t 33 100.00% 1-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/proxy.t 172 113 65.70% 60-172 t/ssl/require.t 52 40.00% 2 5 t/ssl/v2.t11 100.00% 1 t/ssl/varlookup.t72 72 100.00% 1-72 t/ssl/verify.t31 33.33% 2 8 tests and 18 subtests skipped. Failed 13/80 test scripts, 83.75% okay. 234/2824 subtests failed, 91.71% okay. [ error] error running tests (please examine t/logs/error_log) Looking deeper, I replaced Perl with current MacPort perl install and I now get: (The key bit seems it upgrades libwww-perl/5.805 to libwww-perl/5.808.) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 30 15 50.00% 16-30 t/ssl/extlookup.t22 100.00% 1-2 t/ssl/fakeauth.t 32 66.67% 2-3 t/ssl/pr12355.t 108 80.00% 1-8 t/ssl/pr43738.t 44 100.00% 1-4 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 8 tests and 18 subtests skipped. Failed 9/80 test scripts, 88.75% okay. 108/2824 subtests failed, 96.18% okay. [ error] error running tests (please examine t/logs/error_log) Looking at the error and access logs, httpd is returning success and failures where appropriate, but LWP is somehow dying. So, I'll cast my +1 even with these SSL failures as merely changing the LWP version made some of these go away. If someone wants to dig more and see what's up, that'd be appreciated too...but I wouldn't block the release on this. -- justin -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On 1/4/2008 at 1:00 PM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ All 3 are looking good on NetWare Brad
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Phew whit some help I got it all sorted out. Everything seems to be running and functioning at first sight. Atleast my config because I couln't get the test framework to run. Although compiling from a converted source was a pain +1 on this if the final win32-src.zip compiles file after extraction. Jorge On Jan 4, 2008 11:55 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: I'm getting a whole lot of errors with vs 2008 and 2005 on windows: Apr seems to be to blame: --- Error 1 error C2079: 'mip' uses undefined struct 'group_source_req' s:\source\x86\httpd-2.2\srclib\apr\network_io\unix\multicast.c 140 apr Next time, try out the MS SDK beta and give them a bug report before it's too late :) Not APR to blame, it's the MS SDK headers. http://issues.apache.org/bugzilla/show_bug.cgi?id=40398 is the trivial fix for their bogosity. Bill -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, 4 Jan 2008 15:00:46 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. Regression: fails to proxy massively chunked responses. I've just run it on a matrix of two versions: 2.2.7 - clean build 2.2.6+ - 2.2.6 with my proxy fixes I tried httpd from each with modules from each, and got: bin/ modules/ outcome 2.2.6+2.2.6+ success 2.2.6+2.2.7success 2.2.7 2.2.6+ failure 2.2.7 2.2.7failure So it looks like something in core. More detail as and when I figure it out. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Sat, 5 Jan 2008 00:07:42 + Nick Kew [EMAIL PROTECTED] wrote: Regression: fails to proxy massively chunked responses. OK, it works correctly if I revert r602679 (no other changes). Investigating further. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Fri, Jan 04, 2008 at 03:00:46PM -0500, Jim Jagielski wrote: Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ FAILURE!! FAILURE!! FAILURE!! Making all in support /usr/source/httpd-2.0.62/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wall -DDEBUG -g -O9 -march=i686 -DAP_DEBUG -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/source/httpd-2.0.62/srclib/apr/include -I/usr/source/httpd-2.0.62/srclib/apr-util/include -I/usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib -I. -I/usr/source/httpd-2.0.62/os/unix -I/usr/source/httpd-2.0.62/server/mpm/prefork -I/usr/source/httpd-2.0.62/modules/http -I/usr/source/httpd-2.0.62/modules/filters -I/usr/source/httpd-2.0.62/modules/proxy -I/usr/source/httpd-2.0.62/include -I/usr/source/httpd-2.0.62/modules/generators -I/usr/source/httpd-2.0.62/server -I/usr/contrib/include/openssl -I/usr/contrib/include -I/usr/source/httpd-2.0.62/modules/dav/main -export-dynamic -L/usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib -L/usr/contrib/lib -o ab -static ab.lo -lz /usr/source/httpd-2.0.62/srclib/pcre/libpcre.la /usr/source/httpd-2.0.62/srclib/apr-util/libaprutil-0.la /usr/source/httpd-2.0.62/srclib/apr-util/xml/expat/lib/libexpat.la -liconv /usr/source/httpd-2.0.62/srclib/apr/libapr-0.la -lm -ldl -lsslc ld: cannot find -lsslc libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Please fix. Also, someone is overloading mu 2.0.61 server with bogus requests. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Born 29 Jan 1969 Redhill Surrey England -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
The Doctor wrote: libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Yup - and those that do, httpd will pick up --with-sslc. Your config.log might be revealing.
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
William A. Rowe, Jr. wrote: The Doctor wrote: libsslc ??? What the heck? libsslc.a is a proprietary code which very few OSes uses. Yup - and those that do, httpd will pick up --with-sslc. Your config.log might be revealing. Don't bother with your config.log; $ap_ssltk_type of openssl wasn't introduced until rev 2.2.0, apparently in my last patch-merge I missed the ./buildconf to my ./configure, and never caught this locally. In fact, it appears all the 6 year old sslc work didn't land in the tree until the 2.1-dev branch and was never backported. Very sorry about this, the patch is at http://people.apache.org/~wrowe/fix-no-sslc-2.0.patch
