Re: BUG: http_vhost.c:fix_hostname
On Sat, 2002-06-22 at 13:56, Perry Harrington wrote: There is a bug in fix_hostname. The comment above function says that the hostname is lowercased, but it's not. the line which reads: *dst++ = *src++; ... should read: *dst++ = tolower(*src++); Thanks, I'll commit a change to convert to lowercase. All the virtual hosting code that uses r-hostname is case-insensitive, but IMHO it's better to normalize the case early to avoid surprising anyone who later tries to write, for example, a custom vhosting module based on a case-sensitive hash table. --Brian
Re: cvs commit: httpd-2.0/modules/dav/main liveprop.c mod_dav.c mod_dav.h props.c std_liveprop.c util.c util_lock.c
On Sun, Jun 23, 2002 at 06:42:14AM -, [EMAIL PROTECTED] wrote: wrowe 2002/06/22 23:42:14 Modified:modules/dav/main liveprop.c mod_dav.c mod_dav.h props.c std_liveprop.c util.c util_lock.c Log: The real pain. ap-apr xml and text types. hehe... my dirty little secret. Every now and then, I think, oh crap. I gotta go rename all those symbols. Then I forget about it. Actually, it wasn't as bad as I expected it to be. Thanks for the effort! Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: BUG: http_vhost.c:fix_hostname
Brian Pane wrote: On Sat, 2002-06-22 at 13:56, Perry Harrington wrote: There is a bug in fix_hostname. The comment above function says that the hostname is lowercased, but it's not. the line which reads: *dst++ = *src++; ... should read: *dst++ = tolower(*src++); Thanks, I'll commit a change to convert to lowercase. All the virtual hosting code that uses r-hostname is case-insensitive, but IMHO it's better to normalize the case early to avoid surprising anyone who later tries to write, for example, a custom vhosting module based on a case-sensitive hash table. The patch is needed, but I'm afraid it will be a bad idea to insert ++ into tolower(), since under some platforms it is a macro (AND NOT A FUNCTION!) defined by ctype.h, with more than 1 instance of the parameter, so src ends up being incremented by 2, or 3, or even 4. Maybe the following will be better: *dst++ = tolower(*src); ++src; -- Eli Marmor [EMAIL PROTECTED] CTO, Founder 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-23-7338 Kfar-Saba 44641, Israel
Re: BUG: http_vhost.c:fix_hostname
On Sun, 2002-06-23 at 01:18, Eli Marmor wrote:
Brian Pane wrote:
On Sat, 2002-06-22 at 13:56, Perry Harrington wrote:
There is a bug in fix_hostname. The comment above function says that the
hostname
is lowercased, but it's not.
the line which reads:
*dst++ = *src++;
...
should read:
*dst++ = tolower(*src++);
Thanks, I'll commit a change to convert to lowercase. All the virtual
hosting code that uses r-hostname is case-insensitive, but IMHO it's
better to normalize the case early to avoid surprising anyone who later
tries to write, for example, a custom vhosting module based on a
case-sensitive hash table.
The patch is needed, but I'm afraid it will be a bad idea to insert
++ into tolower(), since under some platforms it is a macro (AND NOT
A FUNCTION!) defined by ctype.h, with more than 1 instance of the
parameter, so src ends up being incremented by 2, or 3, or even 4.
Maybe the following will be better:
*dst++ = tolower(*src);
++src;
The change that I committed for this actually looks like:
else if (apr_isalpha(*dst)) {
*dst = apr_tolower(*dst);
}
so it's safe.
But now that you mention it, ap_strcasestr() is vulnerable
to the multiple-increment problem. Fortunately, it's not
actually used anywhere in the core server--and there's probably
no reason to start using it now that apr_strmatch() is available--
but I'll fix the ap_strcasestr() code just in case any third
party modules depend on it.
--Brian
Re: [RHSA-2002:103-13] Updated Apache packages fix chunked encoding issue
On Wed, 19 Jun 2002 19:57:00 -0400, [EMAIL PROTECTED] wrote about [RHSA-2002:103-13] Updated Apache packages fix chunked encoding issue: We have backported the security fix from the official Apache 1.3.26 release. This should help minimize the impact of upgrading to our errata packages. Hi, Since you have backported apache's implementation for ap_strtol, does this mean you suspect glibc's strtol? I believe the latter sets ERANGE correctly, therefore the whole business of replacing strtol by ap_strtol everywhere doen't make sense. The only real fix is the patch of http_protocol.c, where *atol* is replaced by strtol. (of course redhats' apache_1.3.23-chunky.patch does other, unrelated stuff). Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL If you can't say somethin' nice, don't say nothin' at all. -- Thumper (1942) Sunday, 13 Tammuz 5762, 23 June 2002, 5:10PM
RE: worker MPM shutdown
I believe that the problem is platform specific. The reason that loop was added, was to allow for graceless shutdown on linux. On non-linux platforms, killing the main thread kills the whole process, but on linux this doesn't work. The point of closing the sockets was to force the worker threads to finish ASAP so that the process could die. Ryan From: Brian Pane [mailto:[EMAIL PROTECTED]] During the worker MPM non-graceful shutdown, the signal_threads() function attempts to close all open sockets. I have two major objections to this: 1) It's not necessarily safe to close a socket that another thread is using. Note that apr_socket_close() calls the pool cleanup on the pool from which the socket was allocated--bad news if one of the active worker threads happens to be, say, registering a new cleanup in the same pool at the same time. 2) It appears to be contributing to the fact that non-graceful shutdown doesn't work. Without the socket shutdown loop, the child processes shut down promptly. As I understand it, the motivation for closing the sockets during shutdown was to try to fix a race condition in which an active worker thread might be trying to write to a socket at the same time that the underlying pool was being destroyed (due to the recursive destruction of APR's global_pool during apr_terminate()). If so, I think the right solution is to add a way to create parentless pools that aren't implicitly added as children to the global pool, so that a worker thread's pool won't disappear before that thread does. Is there any specific reason why we're not doing this already? Thanks, --Brian
Karma please
Could someone karma me for apache-2.0 please? -Rasmus
Re: Karma please
On Sun, 23 Jun 2002, Rasmus Lerdorf wrote: Could someone karma me for apache-2.0 please? You should use httpd-2.0. The apache-2.0 repository was abandoned long ago. And it looks to me from avail like you already have karma for it (it's the same group as for apache-1.3). --Cliff
Re: Karma please
User rasmus already has karma. apache-2.0 is not what you are looking for, try the module httpd-2.0. Roy On Sunday, June 23, 2002, at 05:30 PM, Rasmus Lerdorf wrote: Could someone karma me for apache-2.0 please? -Rasmus
Apache 2.0 Numbers
Someone asked me for numbers when I mentioned the other day that Apache 2-prefork was really not a viable drop-in replacement for Apache 1.3 when it comes to running a PHP-enabled server. Apache 1.3 is still significantly faster than Apache2-prefork for both static and dynamic content. Now, part of the blame goes to PHP here for the dynamic case. We are compiling PHP in threadsafe mode when building the PHP DSO for Apache2-prefork which is not necessary. It would be nice if there was an apxs flag that would return the MPM type. Right now we would need to parse the output of httpd -l or -V to figure out which MPM is being used. Being able to go non-threadsafe in PHP does speed us up a bit. But none of this has anything to do with the fact that Apache 1.3 is faster for static files. It's going to be very hard to convince people to switch to Apache2-prefork if we can't get it to go at least as fast as 1.3 for simple static files. Platform: Linux 2.4.19-pre8, glibc 2.2.5, gcc-2.96, P3-800, 128M Tested using ab from the httpd-2.0 tree with these flags: -c 5 -n 5 -k 1024-byte file which looked like this: html headtitleTest Document./title body h1Test Document./h1 p This is a 1024 byte HTML file.br / aabr / bbbr / ccbr / ddbr / eebr / ffbr / ggbr / hhbr / iibr / jjbr / kkbr / llbr / mmbr / nnbr / oobr / ppbr / qqbr / rrbr / ssbr / ttbr / uubr / vvbr / wwbr / xxbr / /p /body /html The PHP version was: html headtitleTest Document./title body h1Test Document./h1 p ?='This is a 1024 byte HTML file.'?br / aabr / bbbr / ccbr / ddbr / eebr / ffbr / ggbr / hhbr / iibr / jjbr / kkbr / llbr / mmbr / nnbr / oobr / ppbr / qqbr / rrbr / ssbr / ttbr / uubr / vvbr / wwbr / xxbr / /p /body /html Note the fact that the Apache2 static test produced the wrong number of total bytes. 3072 bytes too many??? Where in the world did they come from? The PHP test on Apache2 produced the correct number as did both static and PHP on Apache1. Apache 2 PreFork KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout15 StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 15 MaxRequestsPerChild 0 STATIC Concurrency Level: 5 Time taken for tests: 23.793270 seconds Complete requests: 5 Failed requests:0 Write errors: 0 Keep-Alive requests:49511 Total transferred: 66681859 bytes HTML transferred: 51203072 bytes === Uh? Requests per second:2101.43 [#/sec] (mean) Time per request: 2.379 [ms] (mean) Time per request: 0.476 [ms] (mean, across all concurrent requests) Transfer rate: 2736.87 [Kbytes/sec] received PHP Concurrency Level: 5 Time taken for tests: 125.831896 seconds Complete requests: 5 Failed requests:0 Write errors: 0 Keep-Alive requests:0 Total transferred: 6325 bytes HTML transferred: 5120 bytes Requests per second:397.36 [#/sec] (mean) Time per request: 12.583 [ms] (mean) Time per request: 2.517 [ms] (mean, across all concurrent requests) Transfer rate: 490.87 [Kbytes/sec] received Apache 1.3 -- Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers10 StartServers5 MaxClients 15 MaxRequestsPerChild 0 --- STATIC --- Concurrency Level: 5 Time taken for tests: 19.735772 seconds Complete requests: 5 Failed requests:0 Write errors: 0 Keep-Alive requests:49507 Total transferred:
Installation problems
Hi All can anyone give me some idea on what i am doing wrong trying to install apache 1.3.24 ./configure --add-module=mod_frontpage.c keep getting the error mod_frontpage.c:896:6: unterminated comment mod_frontpage.c:895:27: unterminated #ifdef make[4]: *** [mod_frontpage.o] Error 1 cheers John
[Fwd: Query: bugs 8712 and 10156]
-Forwarded Message- From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Query: bugs 8712 and 10156 Date: 23 Jun 2002 15:19:31 -0500 I submitted 8712 a month or more ago, and have gotten NO feedback at all. I just submitted 10156 and wonder what it would take to get the patch into the next release. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: CAN-2002-0392 : what about older versions of Apache?
On Sun, Jun 23, 2002 at 05:09:05PM -0700, Roy Fielding wrote: I have re-uploaded a patch to fix the problem on all versions of httpd 1.2.0 through 1.3.22. This time I added the four lines that check for a negative return value from atol, even though there has been no evidence of any such error in the standard C libraries. To the person who deleted my prior patch: You just wasted my Sunday afternoon. Even if the patch didn't, by some stretch of your imagination, suffice for the broken atol case, you prevented people from protecting themselves against a published exploit script that doesn't even use content-length as an attack. Do not remove my patch unless you replace it with a better fix that is known to apply for that version and compile on all platforms. -1 to any additions of ap_strtol to prior versions of Apache. That introduced more problems than it fixed. There is no reason to work around the operating system when a simple fix to our own code is necessary and sufficient to solve the problem. I don't remember seeing any +1's for this patch on the list. Please remove this patch until one can be made that addresses the same issues with the proxy code (which also uses get_chunk_size()). -aaron
RE: CAN-2002-0392 : what about older versions of Apache?
From: Aaron Bannert [mailto:[EMAIL PROTECTED]] On Sun, Jun 23, 2002 at 05:09:05PM -0700, Roy Fielding wrote: I have re-uploaded a patch to fix the problem on all versions of httpd 1.2.0 through 1.3.22. This time I added the four lines that check for a negative return value from atol, even though there has been no evidence of any such error in the standard C libraries. To the person who deleted my prior patch: You just wasted my Sunday afternoon. Even if the patch didn't, by some stretch of your imagination, suffice for the broken atol case, you prevented people from protecting themselves against a published exploit script that doesn't even use content-length as an attack. Do not remove my patch unless you replace it with a better fix that is known to apply for that version and compile on all platforms. -1 to any additions of ap_strtol to prior versions of Apache. That introduced more problems than it fixed. There is no reason to work around the operating system when a simple fix to our own code is necessary and sufficient to solve the problem. I don't remember seeing any +1's for this patch on the list. Please remove this patch until one can be made that addresses the same issues with the proxy code (which also uses get_chunk_size()). The proxy didn't use that code until it supported HTTP 1.1, which didn't happen until 1.3.24. Roy is right, removing this patch is completely bogus. Ryan
Re: CAN-2002-0392 : what about older versions of Apache?
I don't remember seeing any +1's for this patch on the list. I don't remember needing any. There were no -1 with explanations. There certainly hasn't been any effort spent, aside from my own, to address the needs of those who cannot upgrade. You guys punted, so I picked up the ball and finished the task. Somebody has to do it. I refuse to consider votes based on I haven't looked at it yet. Please remove this patch until one can be made that addresses the same issues with the proxy code (which also uses get_chunk_size()). No. Aaron, use your brain. First, the proxy code that implemented chunked reading was introduced after 1.3.22 (hence my NUMEROUS comments to the effect that it wasn't applicable). Second, the bogus type casts were not present until after 1.3.22. Third, the pointless ap_strtol addition was only done because someone wanted to check the errno field, which is totally irrelevant to the security hole itself. My patch does fix the problem, certainly far better than no patch at all. If you disagree, then tell me why it doesn't fix the problem. If all you are going to do is pontificate about the subject without taking the five minutes necessary to review the change, then piss off. Roy
Re: Apache 2.0 Numbers
On Sun, 2002-06-23 at 18:58, Rasmus Lerdorf wrote: Someone asked me for numbers when I mentioned the other day that Apache 2-prefork was really not a viable drop-in replacement for Apache 1.3 when it comes to running a PHP-enabled server. Apache 1.3 is still significantly faster than Apache2-prefork for both static and dynamic content. Most of the static benchmarks that I've seen posted to dev@httpd (including my own tests on Solaris and Linux) indicate otherwise. And for dynamic content, it's tough to make any generalization that one httpd release is faster than another, because the performance depends heavily on one's choice of content generation engine. Now, part of the blame goes to PHP here for the dynamic case. We are compiling PHP in threadsafe mode when building the PHP DSO for Apache2-prefork which is not necessary. You'll definitely see slow performance with PHP and httpd-2.0. I know of two major factors that contribute to this: * mod_php is using malloc and free quite a bit. * PHP's nonbuffered output mode produces very small socket writes with Apache 2.0. With 1.3, the httpd's own output buffering alleviated the problem. In 2.0, where the PHP module splits long blocks of static text into 400-byte segments and inserts a flush bucket after every bucket of data that it sends to the next filter, the result is a stream of rather small packets. It would be nice if there was an apxs flag that would return the MPM type. +1 Right now we would need to parse the output of httpd -l or -V to figure out which MPM is being used. Being able to go non-threadsafe in PHP does speed us up a bit. But none of this has anything to do with the fact that Apache 1.3 is faster for static files. It's going to be very hard to convince people to switch to Apache2-prefork if we can't get it to go at least as fast as 1.3 for simple static files. For what it's worth, I just tried the test case that you posted. On my test system, 2.0 is faster when I run ab without -k, and 1.3 is faster when I run with -k. --Brian
Re: worker MPM shutdown
On Sun, Jun 23, 2002 at 09:44:03PM -0700, Brian Pane wrote: On Sat, 2002-06-22 at 17:01, Ryan Bloom wrote: I believe that the problem is platform specific. The reason that loop was added, was to allow for graceless shutdown on linux. On non-linux platforms, killing the main thread kills the whole process, but on linux this doesn't work. The point of closing the sockets was to force the worker threads to finish ASAP so that the process could die. Why not just pthread_kill() all the workers if we're running on Linux? That would be a much more direct way of stopping them than closing the sockets. That could lead to deadlock if one of our threads happens to be inside of a crossprocess mutex when it is killed. There are solutions to this problem, but they are not pretty. -aaron
Re: Apache 2.0 developer documentation
On Fri, 21 Jun 2002, Arliss, Noah wrote: I've started playing with apache 2.0 with respect to writing modules and I was wondering if there was an ETA for more relavent up to date documentation for developers. Many of the documents including the API document have disclaimers saying Warning: This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care. You might have seen this already, but just in case: the API documentation as it stands is almost all in the header files. See http://docx.webperf.org/ for an HTML-ized version. It's not as descriptive as the old as-yet-not-updated documents you mentioned, but it's definitely helpful, and it's basically all we've got at the moment. Hope this helps. --Cliff
Re: core_output_filter buffering for keepalives? Re: Apache 2.0Numbers
Bill Stoddard wrote: . So changing the AP_MIN_BYTES_TO_WRITE just moves the relative postion of the write() and the check pipeline read. It has one other side-effect, though, and that's what's bothering me: In the case where core_output_filter() decides to buffer a response because it's smaller than 8KB, the end result is to turn: sendfile into: mmap memcpy munmap ... buffer some more requests' output until we have 8KB ... writev ... Some potential low hanging fruit here... would it make sense to make the keepalive read (the one right before the select) an APR_INCOMPLETE_READ? That makes sense. The select ought to be cheaper than the read that returns EAGAIN. --Brian
Re: core_output_filter buffering for keepalives? Re: Apache 2.0 Numbers
On Mon, Jun 24, 2002 at 01:07:48AM -0400, Cliff Woolley wrote: Anyway, what I'm saying is: don't make design decisions of this type based only on the results of an ab run. +1 I think at this point ab should have the ability to interleave issuing new connections, handling current requests, and closing finished requests, but it would be nice if someone else could make sure. If I get a chance I'll try to run flood against the two scenarios -- it tends to get around some of the concurrency problems we see with ab but at the expense of scalability. -aaron
Re: core_output_filter buffering for keepalives? Re: Apache 2.0 Numbers
Bill Stoddard wrote: . So changing the AP_MIN_BYTES_TO_WRITE just moves the relative postion of the write() and the check pipeline read. It has one other side-effect, though, and that's what's bothering me: In the case where core_output_filter() decides to buffer a response because it's smaller than 8KB, the end result is to turn: sendfile into: mmap memcpy munmap ... buffer some more requests' output until we have 8KB ... writev ... Yack... just noticed this too. This renders the fd cache (in mod_mem_cache) virtually useless. Not sure why we cannot setaside a fd. Bill
Re: core_output_filter buffering for keepalives? Re: Apache 2.0Numbers
On Mon, 24 Jun 2002, Bill Stoddard wrote: Yack... just noticed this too. This renders the fd cache (in mod_mem_cache) virtually useless. Not sure why we cannot setaside a fd. You can. The buckets code is smart enough to (a) take no action if the apr_file_t is already in an ancestor pool of the one you're asking to setaside into and (b) just use apr_file_dup() to get it into the requested pool otherwise to handle the pool cleanup/lifetime issues. It's the core_output_filter that's doing an apr_bucket_read() / apr_brigade_write() here. Presumably to minimize the number of buffers that will have to be passed to writev() later. That could be changed pretty easily, and the mmap/memcpy/munmap/writev would go away. Note, however, that since you can only pass one fd to sendfile at a time anyway, delaying the sending of a FILE bucket is pretty pointless if you're going to send it out with sendfile later anyway. What would be better is to mmap the file and hang onto the mmap to pass a bunch of mmap'ed regions to writev() all at once. For cache purposes, that just means that all you have to do is consider the size of the files you're dealing with, and if they're small, use MMapFile instead of CacheFile. If we then got rid of the apr_bucket_read/apr_brigade_write in the core_output_filter and just saved up a brigade instead, you'd be set. --Cliff
