Re: [RELEASE CANDIDATE] libapreq-1.34
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 make, test, install with apache-1.41/perl-5.6.2/mp-1.30 Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org Thanks, Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmeXgACgkQ7bEFiW+VItiqDQCfaLWzLlAsp4PhT8kfHtqfp6p6 rKgAn06AYDSMXdEe1poRp5VDHeasu5p4 =qfzS -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] libapreq-1.34
That's 3 +1s. Uploading to CPAN and announcing... Issac Goldstand wrote: +1 make, test, install with apache-1.41/perl-5.6.2/mp-1.30 Issac Goldstand wrote: The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-dev@httpd.apache.org Thanks, Issac
RE: null pollset
It's definitely this. Thanks! -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Thu 1/8/2009 6:21 AM To: modules-dev@httpd.apache.org Subject: Re: null pollset On 08.01.2009 03:13, Brian Adams wrote: Hi, I just created a new dev box on Fedora 10 and I'm seeing something strange with httpd that I built from source. It's segfaulting constantly (even though I can get pages and modules to execute). If I look at a coredump I see this: (gdb) where #0 apr_pollset_add (pollset=0x0, descriptor=0xbf8aadec) at poll/unix/epoll.c:150 #1 0x080bd161 in child_main (child_num_arg=value optimized out) at prefork.c:532 #2 0x080bd613 in make_child (s=0x8ee4830, slot=1) at prefork.c:746 #3 0x080bdc9a in startup_children () at prefork.c:764 #4 ap_mpm_run (_pconf=0x8edf550, plog=0x8f19638, s=0x8ee4830) at prefork.c:985 #5 0x08069800 in main (argc=Cannot access memory at address 0x0 ) at main.c:740 Looks like apr_pollset_create is failing in prefork.c. Any ideas on why this would happen? Could it be BZ 46467? https://issues.apache.org/bugzilla/show_bug.cgi?id=46467 Regards, Rainer
Re: svn commit: r729586 - in /httpd/httpd/trunk: CHANGES server/util_script.c
On Wed, Jan 07, 2009 at 02:34:29PM -0500, Eric Covener wrote: On Fri, Dec 26, 2008 at 10:53 PM, n...@apache.org wrote: Author: niq Date: Fri Dec 26 19:53:32 2008 New Revision: 729586 URL: http://svn.apache.org/viewvc?rev=729586view=rev Log: CGI: return 504 (Gateway timeout) rather than 500 when a script times out before returning status line/headers. PR 42190 Any concern that canned message for 504 is going to cause confusion? I don't see why 504 is more appropriate than 500 for this case. 504 is specifically defined for cases where the server is acting as a gateway or proxy, which it is not here. (by the 2616 definitions of gateway and proxy) joe
Re: null pollset
On 08.01.2009 03:13, Brian Adams wrote: Hi, I just created a new dev box on Fedora 10 and I’m seeing something strange with httpd that I built from source. It’s segfaulting constantly (even though I can get pages and modules to execute). If I look at a coredump I see this: (gdb) where #0 apr_pollset_add (pollset=0x0, descriptor=0xbf8aadec) at poll/unix/epoll.c:150 #1 0x080bd161 in child_main (child_num_arg=value optimized out) at prefork.c:532 #2 0x080bd613 in make_child (s=0x8ee4830, slot=1) at prefork.c:746 #3 0x080bdc9a in startup_children () at prefork.c:764 #4 ap_mpm_run (_pconf=0x8edf550, plog=0x8f19638, s=0x8ee4830) at prefork.c:985 #5 0x08069800 in main (argc=Cannot access memory at address 0x0 ) at main.c:740 Looks like apr_pollset_create is failing in prefork.c. Any ideas on why this would happen? Could it be BZ 46467? https://issues.apache.org/bugzilla/show_bug.cgi?id=46467 Regards, Rainer
Re: svn commit: r729586 - in /httpd/httpd/trunk: CHANGES server/util_script.c
On 8 Jan 2009, at 10:34, Joe Orton wrote: I don't see why 504 is more appropriate than 500 for this case. 504 is specifically defined for cases where the server is acting as a gateway or proxy, which it is not here. (by the 2616 definitions of gateway and proxy) joe One might consider the G of CGI a clue. The fact that the backend is (usually) an application running locally on the same machine as the webserver doesn't preclude the latter being a gateway. Come to think of it, CGI errors fall into more categories than we allow. A misconfiguration is indeed Internal Server Error. But a script that generates garbage is an External Server Error, and a 502 response would be in order. It would be no bad thing to point the finger of blame at broken scripts rather than confuse the authors with internal errors. -- Nick Kew
Re: svn commit: r729586 - in /httpd/httpd/trunk: CHANGES server/util_script.c
* Nick Kew wrote: On 8 Jan 2009, at 10:34, Joe Orton wrote: I don't see why 504 is more appropriate than 500 for this case. 504 is specifically defined for cases where the server is acting as a gateway or proxy, which it is not here. (by the 2616 definitions of gateway and proxy) joe One might consider the G of CGI a clue. The fact that the backend is (usually) an application running locally on the same machine as the webserver doesn't preclude the latter being a gateway. Come to think of it, CGI errors fall into more categories than we allow. A misconfiguration is indeed Internal Server Error. But a script that generates garbage is an External Server Error, and a 502 response would be in order. It would be no bad thing to point the finger of blame at broken scripts rather than confuse the authors with internal errors. Generally spoken, the message ist mostly not seen by authors, but by users. For *them* it's an opaque error (and should be), no matter what. nd
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
Issac Goldstand wrote: That sounds right and more in line with the normal httpd release procedure - that would mean doing (4) before (1) and leaving the rest as-is. Well, my first attempt at writing that out was close :) Issac go-ahead and make the changes to RELEASE file and re-roll without the polished version. I think we can stick with v1.34 for this one. I'll dedicate some time tonight or tomorrow to test it. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: Issues with mod_disk_cache and htcacheclean
-Ursprüngliche Nachricht-
Von: Neil Gunton
Gesendet: Montag, 5. Januar 2009 23:17
An: dev@httpd.apache.org
Betreff: Re: Issues with mod_disk_cache and htcacheclean
Ruediger Pluem wrote:
This seems to be a bug. Can you please try if the following
patch fixes this?
I applied the patch and rebuilt httpd_proxy successfully. The new
htcacheclean runs ok, but still seems to leave behind the
orphan .header
files. At least, I tried running htcacheclean in single run
mode, thus:
htcacheclean -t -p/var/cache/www -l100M
Then I run my prune_cache_headers perl script, and it seems to still
find a bunch of orphaned .header files to delete. So it
doesn't appear
to have fixed the issue. I did confirm that the patch was applied.
Can you try with the following additional patch and a clean cache?
Afterwards there should only be very very few orphaned header files
left.:
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 732705)
+++ modules/cache/mod_disk_cache.c (working copy)
@@ -558,6 +558,8 @@
str_to_copy = dobj-hdrsfile ? dobj-hdrsfile : dobj-datafile;
if (str_to_copy) {
char *dir, *slash, *q;
+char *dot;
+char *hdrs_file;
dir = apr_pstrdup(p, str_to_copy);
@@ -586,6 +588,18 @@
}
slash = strrchr(q, '/');
*slash = '\0';
+ /*
+ * Check if we just deleted a vary directory. If we did, the
+ * corresponding header file is of no use anymore. So delete
+ * it.
+ */
+ dot = strrchr(slash + 1, '.');
+ if (dot (strcmp(dot + 1, CACHE_VDIR_SUFFIX) == 0)) {
+ *dot = '\0';
+ hdrs_file = apr_pstrcat(p, dir, /, slash + 1,
+ CACHE_HEADER_SUFFIX, NULL);
+ apr_file_remove(hdrs_file, p);
+ }
}
}
}
Regards
Rüdiger
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
Philip M. Gollucci wrote: Issac Goldstand wrote: That sounds right and more in line with the normal httpd release procedure - that would mean doing (4) before (1) and leaving the rest as-is. Well, my first attempt at writing that out was close :) Issac go-ahead and make the changes to RELEASE file and re-roll without the polished version. I think we can stick with v1.34 for this one. Already rolled, and at a mirror near you, as libapreq-1.34.tar.gz I'll call the vote in a separate email
[RELEASE CANDIDATE] libapreq-1.34
The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org Thanks, Issac
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
Issac Goldstand wrote: That sounds right and more in line with the normal httpd release procedure - that would mean doing (4) before (1) and leaving the rest as-is. Pretty much, yup. The confusion reigns when we aren't sure if a user is complaining about 1.34-dev, 1.34-RC1, 1.34-RC2 or 1.34-Gold. So this gives us a very simple binary question (did you grab from SVN or take a release al la CPAN) to decide if the user is running what we expected. And as folks have hinted, version no's are cheap :)
Transfer Patch Rights for mod_fcgid ASF
Hello, I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Tim Jensen tim at rtsports dot com
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
Vote closed with one -1, and no other votes. I guess 2.3.1 was DOA. I think the issues that killed it have been fixed in trunk. Thoughts on starting 2.3.2 early next week? -Paul Paul Querna wrote: Test tarballs for Apache httpd 2.3.1-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; ±1 [ ] Release httpd-2.3.0 as Alpha Vote closes at 7:00 UTC on Thursday January 8 2009.
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
On 08.01.2009 19:33, Paul Querna wrote: Vote closed with one -1, and no other votes. I guess 2.3.1 was DOA. I think the issues that killed it have been fixed in trunk. Thoughts on starting 2.3.2 early next week? There is not yet any fix in trunk for the delayed closing of files when using HTTP KeepAlive (a pool lifecycle issue). I'm not sure whether that is a show stopper for an alpha, but Rüdiger had the intention of trying to fix it. See: http://marc.info/?t=12310246625r=1w=2 It's a problem specific to trunk. You'll quickly run into out of file descriptors whenever concurrency times KeepAliveRequests is bigger than the allowed number of FDs (content files are only closed at the end of the connection instead of end of request). Regards, Rainer
Re: [RELEASE CANDIDATE] libapreq-1.34
+1, tests and installs cleanly on Debian-testing with apache 1.3.41 and mod_perl 1.30 and perl 5.8.x. - Original Message From: Issac Goldstand mar...@beamartyr.net To: APREQ List apreq-...@httpd.apache.org Sent: Thursday, January 8, 2009 11:35:22 AM Subject: [RELEASE CANDIDATE] libapreq-1.34 The apreq developers are planning a maintenance release of libapreq1. This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. Please give the tarball at http://www.apache.org/dist/httpd/libapreq/libapreq-1.34.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org Thanks, Issac
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
On 01/08/2009 08:02 PM, Rainer Jung wrote: On 08.01.2009 19:33, Paul Querna wrote: Vote closed with one -1, and no other votes. I guess 2.3.1 was DOA. I think the issues that killed it have been fixed in trunk. Thoughts on starting 2.3.2 early next week? There is not yet any fix in trunk for the delayed closing of files when using HTTP KeepAlive (a pool lifecycle issue). I'm not sure whether that is a show stopper for an alpha, but Rüdiger had the intention of trying to fix it. I guess this is not a show stopper for alpha but only for GA. Nevertheless I admit that I lost track, so thanks for the reminder. But I don't know when I will find time to get back to this issue again. So solution proposals are welcome :-). Regards Rüdiger
Question about response validity.
In server/core.c: ap_core_translate, the function apr_filepath_merge is called two different times. Most of the errors from apr_filepath_merge relate to resulting local path values that fall outside the valid server path and make sense to return a 403. There is one case here that is not so clear though. Inside apr_filepath_merge, you can also exceed the local system's PATH_MAX and the function returns APR_ENAMETOOLONG. This results in a 403 being returned for a case where we refused to process the request because the resulting local path name exceeded the PATH_MAX value. Should this return 414 when it gets APR_ENAMETOOLONG or is it valid to return 403? -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
[ANNOUNCEMENT] libapreq-1.34 (a.k.a. Apache::Request-1.34) Released
The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 1.34 of the Apache HTTP Request Library (libapreq). This version primarily addresses an issue noted with FireFox 2.0 truncating file uploads in SSL mode. Additionally, the memory allocation algorithm for multipart requests has been improved. We consider this release to be the best version of libapreq-1.x available, and encourage users of all prior versions to upgrade. libapreq-1.34 can be downloaded from the Apache Software Foundation at the following address: http://httpd.apache.org/apreq/download.html libapreq-1.34 is also available at a CPAN mirror near you, and has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/libapreq-1.34.tar.gz size: 314952 bytes md5: 2bee94cf9f36fb156b794bd469fcc550
Re: [VOTE] Release Apache HTTP server 2.3.1-alpha
Paul Querna wrote: Vote closed with one -1, and no other votes. I guess 2.3.1 was DOA. I think the issues that killed it have been fixed in trunk. Thoughts on starting 2.3.2 early next week? +1 :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Question about response validity.
Paul J. Reder wrote: In server/core.c: ap_core_translate, the function apr_filepath_merge is called two different times. Most of the errors from apr_filepath_merge relate to resulting local path values that fall outside the valid server path and make sense to return a 403. There is one case here that is not so clear though. Inside apr_filepath_merge, you can also exceed the local system's PATH_MAX and the function returns APR_ENAMETOOLONG. This results in a 403 being returned for a case where we refused to process the request because the resulting local path name exceeded the PATH_MAX value. Should this return 414 when it gets APR_ENAMETOOLONG or is it valid to return 403? We've treated this as an 'oh - I can't find that resource' because, well, it's not possible. You don't want things like 414's for GET in terms of establishing too many fingerprints. But in DAV, a 414 might make perfect sense (as a PUT).
Re: Transfer Patch Rights for mod_fcgid ASF
Hi, Thank you Tim Jensen :) These are the Major patchs which I thought I should ask the patch authors: Major patches version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Version2.2 (Jul 31st 2007) 3. Support configuration TimeScore Thank Tim Jensen for the patch. (This is a patch from sourceforge.net: https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268, author is https://sourceforge.net/users/timjensen66/) Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? - Original Message - From: Tim Jensen t...@rtsports.com To: dev@httpd.apache.org Sent: Friday, January 09, 2009 2:05 AM Subject: Transfer Patch Rights for mod_fcgid ASF Hello, I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Tim Jensen tim at rtsports dot com
