Re: [PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1
Hi, I have LynxOS-3.0.1 and if you try to use find with -depth obtain a syntax error! find . -depth -print find: syntax error at -depth Maybe it is possible (I don't try to do this) to install the GNU findutils and this can resolve the problem but the find distributed with this version of the LynxOS doesn't support -depth option. Bye, Fulvio Bille` Jim Jagielski wrote: Not sure if they went through, or if I just missed the reply. These patches look good but I have a question about this: At 1:51 PM +0200 7/10/02, Fulvio Bille` wrote: diff -ruN ./src/helpers/mkshadow.sh ../apache_1.3.26-patched/src/helpers/mkshadow.sh --- ./src/helpers/mkshadow.sh Tue Jun 29 15:43:15 1999 +++ ../apache_1.3.26-patched/src/helpers/mkshadow.sh Fri Jul 5 14:11:19 2002 @@ -65,7 +65,7 @@ # fill directory tree with symlinks to files FILES=`cd $src; \ -find . -depth -print |\ +find . -print |\ sed -e '/\.o$/d' \ -e '/\.a$/d' \ -e '/\.so$/d' \ Why the change? Does LynxOS-3.0.1 find not support -depth? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 2.0.40 (prerelease) is available for testing
On Tue, Jul 16, 2002 at 08:49:29PM -0500, William A. Rowe, Jr. wrote: However, we didn't destroy ap_get_client_block until May 30, 2002. If you could please clarify what you mean by 'destroy ap_get_client_block,' that would be greatly appreciated. All that commit should have done was reimplement it not break it. If there was any breakage, it was certainly unintentional. -- justin
Re: environment in mod_ext_filter
Craig Sebenik [EMAIL PROTECTED] writes: In modules/experimental/mod_ext_filter.c there's the following: rc = apr_proc_create(ctx-proc, ctx-filter-command, (const char * const *)ctx-filter-args, NULL, /* environment */ ctx-procattr, ctx-p); Is there a reason why the environment is null? probably because I'm a moron :) Am I missing something? Is there a reason I shouldn't submit this patch? no, no -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] We have sysvsem on OpenBSD
Henning Brauer [EMAIL PROTECTED] writes: we have sysvsem on OpenBSD and applied the following patch to ap_config.h in our tree - would be nice to have it in the apache.org tree as well. this is for apache 1.3. Index: src/include/ap_config.h === RCS file: /cvs/src/usr.sbin/httpd/src/include/ap_config.h,v retrieving revision 1.10 diff -u -r1.10 ap_config.h --- src/include/ap_config.h 29 Mar 2002 02:08:05 - 1.10 +++ src/include/ap_config.h 9 Jul 2002 06:42:15 - @@ -687,7 +687,11 @@ #define HAVE_MMAP 1 #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES +#if defined __OpenBSD__ +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#else #define HAVE_FLOCK_SERIALIZED_ACCEPT +#endif #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT #elif defined(UTS21) I would have thought you would add #if defined __OpenBSD__ #define HAVE_SYSVSEM_SERIALIZED_ACCEPT #endif since you have flock too. If you want to force sysvsem be the default, add #define USE_SYSVSEM_SERIALIZED_ACCEPT in the __OpenBSD__ path. This way you allow the admin to choose flock if they really want. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] 64bit compiler issues
Hi, On Tue, Jul 16, 2002 at 06:01:08PM -0700, Greg Stein wrote: On Tue, Jul 16, 2002 at 10:31:46AM -0500, William A. Rowe, Jr. wrote: At 07:23 PM 7/15/2002, Ryan Bloom wrote: We could force the size, by using apr_int32_t. The problem that he is There is no need to force the size. The value is a simple integer. There is no need to make it a long, and that integer will always be castable into a void*, and then back (when we pull it out of the hash table). I see no purpose in the patch's casting to a long. What exactly is that solving? We need a response from Peter. Sorry for keeping you waiting on this. [...] * mod_dav's namespace indexes are integers * we stuff those into a hash table * we extract them from a hash table Peter's patch changes the indexes to longs. Why? The code assumes that a pointer == int == 32 bit. While in fact int is 32 bit wide on all architectures, a pointer is sized long on 64 bit architectures... What the compiler sees is that a pointer is put into an incompatible type. It warns, and it can't know which actual values will occur at runtime. The patch was meant to take care of these possibly dangerous cases, while ignoring the more obvious harmless ones. But I'm certainly okay if you say that all these values are indices that actually never grow larger than int -- it's you who have the deep understanding of the code, not me. So, if you say that long wasts too many resources, we'll have to live with the compiler warnings; but at least we know that the could should work :^} Anyway, even if the code is safe in all places, one could argue that it is not written in a clean way, making assumptions about the pointer size. I would find it desirable if we could get rid of all benign warnings, so that actual harmful ones do not get lost in the noise. The stderr output of make (using gcc 3.1.1 20020708) is this: protocol.c: In function `ap_note_digest_auth_failure': protocol.c:1102: warning: long long unsigned int format, apr_time_t arg (arg 4) http_core.c: In function `chunk_filter': http_core.c:216: warning: long long unsigned int format, long unsigned int arg (arg 4) http_protocol.c: In function `ap_byterange_filter': http_protocol.c:2839: warning: long long unsigned int format, apr_time_t arg (arg 3) ab.c: In function `output_html_results': ab.c:1103: warning: long long int format, long int arg (arg 5) ab.c:1103: warning: long long int format, long int arg (arg 6) mod_disk_cache.c:431: warning: `remove_url' defined but not used mod_mem_cache.c: In function `set_max_cache_size': mod_mem_cache.c:1049: warning: int format, different type arg (arg 3) mod_mem_cache.c: In function `set_min_cache_object_size': mod_mem_cache.c:1060: warning: int format, different type arg (arg 3) mod_mem_cache.c: In function `set_max_cache_object_size': mod_mem_cache.c:1071: warning: int format, different type arg (arg 3) mod_mem_cache.c: In function `set_max_object_count': mod_mem_cache.c:1082: warning: int format, different type arg (arg 3) cache_pqueue.c: In function `cache_pq_dump': cache_pqueue.c:259: warning: int format, different type arg (arg 7) mod_log_config.c: In function `log_request_duration': mod_log_config.c:548: warning: long long int format, long int arg (arg 3) mod_log_config.c: In function `log_request_duration_microseconds': mod_log_config.c:553: warning: long long int format, apr_time_t arg (arg 3) mod_expires.c: In function `add_expires': mod_expires.c:502: warning: long long int format, long int arg (arg 3) mod_headers.c: In function `header_request_duration': mod_headers.c:185: warning: long long int format, apr_time_t arg (arg 3) mod_headers.c: In function `header_request_time': mod_headers.c:189: warning: long long int format, apr_time_t arg (arg 3) mod_usertrack.c: In function `make_cookie': mod_usertrack.c:149: warning: long long int format, apr_time_t arg (arg 5) ssl_scache_shmcb.c: In function `ssl_scache_shmcb_init': ssl_scache_shmcb.c:391: warning: unsigned int format, different type arg (arg 7) ssl_scache_shmht.c: In function `ssl_scache_shmht_init': ssl_scache_shmht.c:177: warning: int format, different type arg (arg 8) liveprop.c: In function `dav_register_liveprop_namespace': liveprop.c:83: warning: cast from pointer to integer of different size liveprop.c:91: warning: cast to pointer from integer of different size liveprop.c: In function `dav_get_liveprop_ns_index': liveprop.c:96: warning: cast from pointer to integer of different size liveprop.c: In function `dav_add_all_liveprop_xmlns': liveprop.c:115: warning: cast from pointer to integer of different size mod_cgid.c: In function `close_unix_socket': mod_cgid.c:938: warning: cast from pointer to integer of different size mod_cgid.c: In function `connect_to_daemon': mod_cgid.c:981: warning: cast to pointer from integer of different size mod_cgid.c: In function `cgid_handler': mod_cgid.c:1241: warning: cast to pointer from integer of different size mod_cgid.c:1253: warning: cast to pointer
Re: FileDescriptorLimit ScriptsockBacklog (was: [PATCH] increase file descriptor limit automatically at httpd start up)
Tsuyoshi SASAMOTO [EMAIL PROTECTED] writes: How about to make a new directive such as FileDescriptorLimit? I think this was solved differently. Also, how about ScriptsockBacklog - to specify the backlog number of the cgid socket. +1, but can you figure out what is messed up with the parts of your patch to add ScriptsockBacklog? The patch shows a lot of lines changed when they look the same (whitespace inadvertently changed I guess). I don't have time to hand-merge it. Thanks a bunch, Jeff -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] make pathnames in ssl-std.conf configurable
On Tue, Jul 16, 2002 at 03:54:36PM -0700, Justin Erenkrantz wrote: On Mon, Jul 15, 2002 at 06:57:05PM +0200, Peter Poeml wrote: Hi, I'd like to propose to create ssl-std.conf from ssl-std.conf.in, just as it is done with httpd-std.conf.in. Then, the log file paths could be substituted in the same flexible way. Currently, of patching / hand editing is necessary for adjustments in that file. In the past, we have been relucant to have SSL work for people out-of-the-box. I understand. I don't have a problem with adding this, but I would like some buy-in from others before committing this. I think we've discussed this before and the consensus was not to subsitute values for ssl-std.conf. -- justin Hhm, but mod_ssl conveniently patched conf/httpd.conf-dist to contain the pathnames enclosed in ..., so they would be substituted together with all other pathnames in httpd.conf-dist. So now it is harder than before... Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 08:42:33AM -0400, Jeff Trawick wrote: I would have thought you would add #if defined __OpenBSD__ #define HAVE_SYSVSEM_SERIALIZED_ACCEPT #endif since you have flock too. If you want to force sysvsem be the default, add #define USE_SYSVSEM_SERIALIZED_ACCEPT in the __OpenBSD__ path. This way you allow the admin to choose flock if they really want. you're right. I'm on committing that change. as we have privilege seperation (chroot drop root privs in the parent) now per default we don't want flock, no files writeable by www inside ServerRoot.
Re: [PATCH] We have sysvsem on OpenBSD
Henning Brauer wrote: sorry if this appears twice, first one seems not to have made it. we have sysvsem on OpenBSD and applied the following patch to ap_config.h in our tree - would be nice to have it in the apache.org tree as well. this is for apache 1.3. Index: src/include/ap_config.h === RCS file: /cvs/src/usr.sbin/httpd/src/include/ap_config.h,v retrieving revision 1.10 diff -u -r1.10 ap_config.h --- src/include/ap_config.h 29 Mar 2002 02:08:05 - 1.10 +++ src/include/ap_config.h 9 Jul 2002 06:42:15 - @@ -687,7 +687,11 @@ #define HAVE_MMAP 1 #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES +#if defined __OpenBSD__ +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#else #define HAVE_FLOCK_SERIALIZED_ACCEPT +#endif Why the #else part? Does OpenBSD lack flock() or is it because of the new 'chroot' that your version does, but the .org doesn't. If the latter, I'd prefer allowing both with the official ASF code. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 09:18:34AM -0400, Jim Jagielski wrote: Henning Brauer wrote: sorry if this appears twice, first one seems not to have made it. we have sysvsem on OpenBSD and applied the following patch to ap_config.h in our tree - would be nice to have it in the apache.org tree as well. this is for apache 1.3. Index: src/include/ap_config.h === RCS file: /cvs/src/usr.sbin/httpd/src/include/ap_config.h,v retrieving revision 1.10 diff -u -r1.10 ap_config.h --- src/include/ap_config.h 29 Mar 2002 02:08:05 - 1.10 +++ src/include/ap_config.h 9 Jul 2002 06:42:15 - -687,7 +687,11 #define HAVE_MMAP 1 #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES +#if defined __OpenBSD__ +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#else #define HAVE_FLOCK_SERIALIZED_ACCEPT +#endif Why the #else part? Does OpenBSD lack flock() or is it because of the new 'chroot' that your version does, but the .org doesn't. If the latter, I'd prefer allowing both with the official ASF code. oversight on our part. I just commited a fix. flock works with out chroot, but we don't want www-writeable files inside the chroot, so we default to sysvsem.
Re: [PATCH] 64bit compiler issues
Peter Poeml [EMAIL PROTECTED] writes: The stderr output of make (using gcc 3.1.1 20020708) is this: a number of these are easily fixable and don't deal with passing an int in a ptr field... I'll see what I can do this a.m. and you get to see how many of my attempts actually helped :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] autoconf macros: quote macro names
On Tue, Jul 16, 2002 at 03:50:45PM -0700, Justin Erenkrantz wrote: On Mon, Jul 15, 2002 at 06:01:10PM +0200, Peter Poeml wrote: Hi, in the autoconf macro definitions of acinclude.m4, the macro names are not quoted as suggested in the autoconf documentation for AC_DEFUN: [...] Be sure to properly quote both the MACRO-BODY _and_ the MACRO-NAME to avoid any problems if the macro happens to have been previously defined. [...] The missing quotes actually lead to problems when running autoreconf with recent autoconf versions. What versions of autoconf have this problem? -- justin I'm not entirely sure -- at least with 2.52 and 2.53 it occurs here. They end up in a recursion loop: chroot ROOT@pepper /usr/src/packages/BUILD/httpd-2.0.39/ # aclocal chroot ROOT@pepper /usr/src/packages/BUILD/httpd-2.0.39/ # autoconf /usr/bin/m4: acinclude.m4: 289: ERROR: Recursion limit of 1024 exceeded, use -LN to change it This happens not only in our stable branch but also on SuSE Linux 8.0. However, obviously the configure script packaged with the 2.0.39 tarball has been created with autoconf 2.53. So it seems to work for you, somehow. Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 03:22:54PM +0200, Henning Brauer wrote: flock works with out chroot, but we don't want www-writeable files inside the chroot, so we default to sysvsem. flock works with our chroot, that is.
Re: [PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1
At 8:49 AM +0200 7/17/02, Fulvio Bille` wrote: Hi, I have LynxOS-3.0.1 and if you try to use find with -depth obtain a syntax error! find . -depth -print find: syntax error at -depth Maybe it is possible (I don't try to do this) to install the GNU findutils and this can resolve the problem but the find distributed with this version of the LynxOS doesn't support -depth option. Thanks! I'm curious why the problem didn't exist (or wasn't reported to exist) in other LynxOS versions. I'll take a look. Thanks again for the patches and for using Apache! -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] We have sysvsem on OpenBSD
Henning Brauer wrote: Why the #else part? Does OpenBSD lack flock() or is it because of the new 'chroot' that your version does, but the .org doesn't. If the latter, I'd prefer allowing both with the official ASF code. oversight on our part. I just commited a fix. flock works with out chroot, but we don't want www-writeable files inside the chroot, so we default to sysvsem. Looks like some messages were passing right by each other. I see the other thread on the same topic :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] We have sysvsem on OpenBSD
Henning Brauer [EMAIL PROTECTED] writes: On Wed, Jul 17, 2002 at 08:42:33AM -0400, Jeff Trawick wrote: I would have thought you would add #if defined __OpenBSD__ #define HAVE_SYSVSEM_SERIALIZED_ACCEPT #endif since you have flock too. If you want to force sysvsem be the default, add #define USE_SYSVSEM_SERIALIZED_ACCEPT in the __OpenBSD__ path. This way you allow the admin to choose flock if they really want. you're right. I'm on committing that change. does everybody agree that this is preferable? Index: src/include/ap_config.h === RCS file: /home/cvs/apache-1.3/src/include/ap_config.h,v retrieving revision 1.323 diff -u -r1.323 ap_config.h --- src/include/ap_config.h 3 Jun 2002 12:28:27 - 1.323 +++ src/include/ap_config.h 17 Jul 2002 14:23:39 - @@ -688,6 +688,10 @@ #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES #define HAVE_FLOCK_SERIALIZED_ACCEPT +#if defined(__OpenBSD__) +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#define USE_SYSVSEM_SERIALIZED_ACCEPT +#endif #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT #elif defined(UTS21) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] We have sysvsem on OpenBSD
Jeff Trawick wrote: does everybody agree that this is preferable? Index: src/include/ap_config.h === RCS file: /home/cvs/apache-1.3/src/include/ap_config.h,v retrieving revision 1.323 diff -u -r1.323 ap_config.h --- src/include/ap_config.h 3 Jun 2002 12:28:27 - 1.323 +++ src/include/ap_config.h 17 Jul 2002 14:23:39 - @@ -688,6 +688,10 @@ #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES #define HAVE_FLOCK_SERIALIZED_ACCEPT +#if defined(__OpenBSD__) +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#define USE_SYSVSEM_SERIALIZED_ACCEPT +#endif #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 10:31:44AM -0400, Jeff Trawick wrote: does everybody agree that this is preferable? Index: src/include/ap_config.h === RCS file: /home/cvs/apache-1.3/src/include/ap_config.h,v retrieving revision 1.323 diff -u -r1.323 ap_config.h --- src/include/ap_config.h 3 Jun 2002 12:28:27 - 1.323 +++ src/include/ap_config.h 17 Jul 2002 14:23:39 - -688,6 +688,10 #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES #define HAVE_FLOCK_SERIALIZED_ACCEPT +#if defined(__OpenBSD__) +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#define USE_SYSVSEM_SERIALIZED_ACCEPT +#endif #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT #elif defined(UTS21) that's exactly what I've commited in our tree, so I do agree ;-)
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 10:31:44AM -0400, Jeff Trawick wrote: does everybody agree that this is preferable? Why isn't this being detected by autoconf? SysV semaphore support isn't perfect yet and has some problems. -aaron Index: src/include/ap_config.h === RCS file: /home/cvs/apache-1.3/src/include/ap_config.h,v retrieving revision 1.323 diff -u -r1.323 ap_config.h --- src/include/ap_config.h 3 Jun 2002 12:28:27 - 1.323 +++ src/include/ap_config.h 17 Jul 2002 14:23:39 - -688,6 +688,10 #define USE_MMAP_SCOREBOARD #define USE_MMAP_FILES #define HAVE_FLOCK_SERIALIZED_ACCEPT +#if defined(__OpenBSD__) +#define HAVE_SYSVSEM_SERIALIZED_ACCEPT +#define USE_SYSVSEM_SERIALIZED_ACCEPT +#endif #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT #elif defined(UTS21)
RE: [PATCH] We have sysvsem on OpenBSD
From: Aaron Bannert [mailto:[EMAIL PROTECTED]] On Wed, Jul 17, 2002 at 10:31:44AM -0400, Jeff Trawick wrote: does everybody agree that this is preferable? Why isn't this being detected by autoconf? SysV semaphore support isn't perfect yet and has some problems. Because this is Apache 1.3 which doesn't use autoconf. :-) Ryan
Re: [PATCH] We have sysvsem on OpenBSD
On Wed, Jul 17, 2002 at 07:23:08AM -0700, Ryan Bloom wrote: Why isn't this being detected by autoconf? SysV semaphore support isn't perfect yet and has some problems. Because this is Apache 1.3 which doesn't use autoconf. :-) This is my brain -= sleep. :) -aaron
Apache 1.3.26 on 64 bit Windows machines
Is Apache 1.3.26 safe to build/run on 64 bit Windows platforms? Thanks! Mark
Re: Apache 1.3.26 on 64 bit Windows machines
At 12:03 PM 7/17/2002, Mark Nelson wrote: Is Apache 1.3.26 safe to build/run on 64 bit Windows platforms? As a 32 bit app? Yes. Short of that, it has many, many problems building on Win64. We aren't investing any further effort [aside from bug fixes] for the 1.3/win32 port. The Win64 effort is entirely focused on 2.0 with APR. There are too many known side effects in the 1.3 code base, that could only be resolved by the 2.0 transition to the Apache Portability Runtime. With those changes, Apache is now about one order of magnitude faster with 2.0 on Win32. You can see why long-term support of 1.3 isn't a terribly interesting investment of time by most Win32 volunteers. There is no small handful of problems with the 2.0 version and Win64 compatibility, but we are addressing them as we go. If you have patches to submit to the 2.0 version, I would be very happy to review and fix the bugs or apply patches. Bill
``List-Unsubscribe''
_ Webdunia Quiz Contest - Limited Time Unlimited Fun.Log on to quiz.webdunia.com and win fabulous prizes. India's first multilingual mailing system: Get your Free e-mail account at www.epatra.com
Re: [PATCH] ftp proxy by IPv6
Shoichi Sakane [EMAIL PROTECTED] writes: your question means if i can modify ftp proxy to use the function ap_proxy_connect_to_backend() ? yes, that was my original question... I just committed your patch with very minor modifications. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
[PATCH] C-L POST body wouldn't report EOS
Attached is a patch that should allow ap_get_brigade() modules to
determine EOS on the same roundtrip as the last read of the request
body contents.
Right now, the caller won't receive an EOS. Coupled with our useless
r-remaining req_rec member, there is no way to determine if there is
no data left to read.
With this patch, pulling a small (say, 200 byte) POST request will
now return the 200 byte bucket, plus the EOS bucket signifying that
we have nothing left to read from the client.
I don't have any immediate proposal on chunked post bodies, but this
should be considered separately any ways.
Bill
Index: CHANGES
===
RCS file: /home/cvs/httpd-2.0/CHANGES,v
retrieving revision 1.868
diff -u -r1.868 CHANGES
--- CHANGES 17 Jul 2002 17:55:58 - 1.868
+++ CHANGES 17 Jul 2002 18:43:16 -
@@ -1,5 +1,10 @@
Changes with Apache 2.0.40
+ *) Modified the HTTP_IN filter to immediately append the EOS (end of
+ stream) bucket for C-L POST bodies, saving a roundtrip and allowing
+ the caller to determine that no content remains without prefetching
+ additional POST body. [William Rowe]
+
*) Get proxy ftp to work over IPv6. [Shoichi Sakane [EMAIL PROTECTED]]
*) Look for OpenSSL libraries in /usr/lib64. [Peter Poeml [EMAIL PROTECTED]]
Index: modules/http/http_protocol.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.448
diff -u -r1.448 http_protocol.c
--- modules/http/http_protocol.c17 Jul 2002 13:50:26 - 1.448
+++ modules/http/http_protocol.c17 Jul 2002 18:43:22 -
@@ -1025,6 +1025,14 @@
ctx-remaining -= totalread;
}
+/* If we have no more bytes remaining on a C-L request,
+ * save the callter a roundtrip to discover EOS.
+ */
+if (ctx-state == BODY_LENGTH ctx-remaining == 0) {
+e = apr_bucket_eos_create(f-c-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(b, e);
+}
+
/* We have a limit in effect. */
if (ctx-limit) {
/* FIXME: Note that we might get slightly confused on chunked inputs
Re: [PATCH] C-L POST body wouldn't report EOS
On Wed, Jul 17, 2002 at 01:48:52PM -0500, William A. Rowe, Jr. wrote: Attached is a patch that should allow ap_get_brigade() modules to determine EOS on the same roundtrip as the last read of the request body contents. +1. -- justin
Re: [PATCH] C-L POST body wouldn't report EOS
Justin Erenkrantz wrote: On Wed, Jul 17, 2002 at 01:48:52PM -0500, William A. Rowe, Jr. wrote: Attached is a patch that should allow ap_get_brigade() modules to determine EOS on the same roundtrip as the last read of the request body contents. +1. -- justin I haven't had a chance to look at the code, but +1 on the concept. --Brian
Re: environment in mod_ext_filter
Quoting Jeff Trawick ([EMAIL PROTECTED]): Craig Sebenik [EMAIL PROTECTED] writes: Is there a reason why the environment is null? probably because I'm a moron :) :) *Probably*??? You're not sure? :) Am I missing something? Is there a reason I shouldn't submit this patch? no, no I put it in as a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10925 The dev guidelines say that patches can be submitted either via an email (to this list) or via the bug database. But, it doesn't say which is preferred... I guess different people would have different preferences... Anyway, it's there... I could send it to the list also, if you prefer. You'll notice that I put in a call to ap_add_cgi_vars, which may be a little excessive (or down right wrong). So, that is up for discussion. Craig
Re: [PATCH] mod_rewrite and cookie setting
On Tue, Jul 16, 2002 at 12:15:41PM -0700, Adam Sussman wrote: On Tue, Jul 16, 2002 at 10:26:49AM -0700, Ian Holsman wrote: Adam Sussman wrote: The new cookie setting feature of mod_rewrite adds the Set-Cookie header to r-headers_out. Shouldn't this be r-err_headers_out instead? The error headers are always present whereas the the normal headers do not appear under error conditions. In applications where I have an apache module setting cookies, I have always found that setting err_headers_out gives me the complete coverage that I want. Thoughts? yep.. a couple of them the original patch has err_headers_out and it didn't work as we would get multiple cookies back on a simple request on GET / on a standard install. hmm... I cannot reproduce this behaviour. So far as I can see, the only difference is whether or not the cookie header appears in non-200 reponses. Can you show me the configuration you used? Here's an example that will trigger the same cookie being set twice when the cookies are in err_headers_out: RewriteRule ^(.*)$ - [CO=MYCOOKIE:$1:.apache.org] If you used this and requested / it would get an internal redirecto to /index.html, therefore you'd get two SetCookie headers, one for MYCOOKIE=/ and another for MYCOOKIE=/index.html This could be a problem for you. However, if it's not in err_headers_out there's even a bigger problem. mod_rewrite uses internal redirects for rewrite rules that are placed in Directory and Location tags because the directory_walk and location_walk phases execute after the translate_name phase. Therefore, if you don't put the cookie in err_headers_out, it will get set in r-main, then the internal_redirect issues and the cookie never gets sent to the requestor. So we're screwed either way. One way I've thought of to fix this is to alter mod_rewrite so that it translates the name in the map_to_storage phase for rules inside of Directory and Location sections. I haven't tried this though. Any thoughts? -bmd
Re: [PATCH] ftp proxy by IPv6
your question means if i can modify ftp proxy to use the function ap_proxy_connect_to_backend() ? yes, that was my original question... i can't say yes, but if i will be able to have a free time and if the issue will remain, then i will try it. I just committed your patch with very minor modifications. thank you.
daedalus is running httpd-2.0.pre40
...since Wednesday, 17-Jul-2002 18:49:31 PDT . Things look fine now, but we took about a 3 1/2 minute site outage because of: [Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not open mime types config file /usr/local/apache/conf/mime.types. Configuration Failed That's the feechur where we no longer copy existing conf/ directories at make install time. Remind me again: what was wrong with simply not overlaying existing files? Greg
[STATUS] (apache-1.3) Wed Jul 17 23:45:05 EDT 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/06/27 20:57:21 $] Release: 1.3.27-dev: In development 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * Backport of 2.0 ForceLanguagePriority directive /dist/httpd/contrib/patches/1.3/force_language_priority.patch Message-ID: [EMAIL PROTECTED] Status: * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia [EMAIL PROTECTED]' patch to allow DirectoryIndex to refer to URIs for non-static resources.
Re: cvs commit: httpd-2.0 STATUS
On 17 Jul 2002 [EMAIL PROTECTED] wrote: trawick 2002/07/17 15:15:01 Modified:.STATUS Log: somebody please tell me I don't know how to read C code anymore (I guess the pool for an Apache socket will grow on every read/write operation that would block.) +* apr_poll() grows the pool (e.g., pchild or the thread's pool) on + each call... Apache MPMs don't have logic to work around this + issue. Well the goal was to optimize out that palloc over time, which just requires some profiling to find the most likely cases. Also, on platforms with alloca, we can allocate the pollset on the stack. All of this has been spelled out on the list, but I haven't had the time to do it yet. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: On 17 Jul 2002 [EMAIL PROTECTED] wrote: trawick 2002/07/17 15:15:01 Modified:.STATUS Log: somebody please tell me I don't know how to read C code anymore (I guess the pool for an Apache socket will grow on every read/write operation that would block.) +* apr_poll() grows the pool (e.g., pchild or the thread's pool) on + each call... Apache MPMs don't have logic to work around this + issue. Well the goal was to optimize out that palloc over time, which just requires some profiling to find the most likely cases. Also, on platforms with alloca, we can allocate the pollset on the stack. All of this has been spelled out on the list, but I haven't had the time to do it yet. What's the plan for handling apr_poll() calls with really large numbers of descriptors? It's trivial to optimize for small numbers of descriptors by putting a pollset on the stack, but that won't work if someone tries to use apr_poll with, say, a thousand descriptors. And an app that passes that many descriptors to poll is likely running an event loop in which it will keep calling poll over and over, so we won't be able to use apr_palloc() there. --Brian
[PATCH] libhttpd.dsp
Removes the long ago deleted mpm_status.h from the project file. Shane Index: libhttpd.dsp === RCS file: /home/cvspublic/httpd-2.0/libhttpd.dsp,v retrieving revision 1.48 diff -u -r1.48 libhttpd.dsp --- libhttpd.dsp13 Jul 2002 06:33:13 - 1.48 +++ libhttpd.dsp18 Jul 2002 04:33:21 - -615,10 +615,6 # Begin Source File SOURCE=.\server\mpm\winnt\mpm_default.h -# End Source File -# Begin Source File - -SOURCE=.\include\mpm_status.h # End Source File # Begin Source File
