Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Geoffrey Young wrote: I think the attached patch behaves as suggested. perfectly, thanks.
Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Doug MacEachern wrote: On Wed, 18 Sep 2002, Geoffrey Young wrote: I think the attached patch behaves as suggested. perfectly, thanks. with 5.8.0 that is. with 5.6.1, dies with: Error in option spec: verbose:1
Re: newbie question on perl-framework...
On Tue, 17 Sep 2002, David Hill wrote: Tried that (twice) and it did not help. Thanks for the pointer to the config blocks, missed that in my RTFM-ing. If I hand hack a conf file based on your pointer, things run much better, but what a pain t/TEST -clean t/TEST -trace=debug will give you some more info. I am beginning to think that the problem is related to the path to the libraries created by apxs. The DSO is created as ./c-modules/foo/.libs/libmod_foo.so I am trying to understand the perl code but have not found anything that deals with this stuff. that path is expected. if the .so isn't found, then it shouldn't be added to httpd.conf and tests skipped that depend on that module. you might want to look at the generated file: t/conf/apache_test_config.pm contains most of the collected info, including a list of cmodules from the c-modules directory.
(forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]
I'm forwarding this debian bug onto the dev list for discussion and
comments.
please can the cc line ([EMAIL PROTECTED]) be maintained so the bug
gets a record of this?
Cheers,
-Thom
--
Thom May - [EMAIL PROTECTED]
robster SHIT
robster woody doesnt support devfs
willy devfs is FUcking Shit
liiwi willy: quick now! tell it to stop before it gets itself dirty!
---BeginMessage---
Package: apache2
Version: N/A; reported 2002-09-17
Severity: normal
Tags: patch
Shared memory (as used by at least the ssl module) needs to rethink
how they go about cleaning it up. Currently kill -9 the apache
processes or it would appear that even /etc/init.d/apache2 reload will
cause apache to fail to start because the shared memory segment can't
be created since it already exists.
There are a couple solutions to this. If the shared memory segment
already exists just attach to it, but this has security issues.
If the shared memory segment already exists pick another magic number
and try again, this could eventually leave many unused shared memory
regious laying around.
This is how I've done it in the past. Allocate the shared memory
segment, attach to it, delete it. It will stick around until the last
process detaches. We just need to use the shmid to attach to our
segment instead of using the key.
Here is a patch to fix it. I only have Unix so I couldn't test the
other platforms, something will have to be done about OS/2 and the
rest.
Index: modules/ssl/ssl_scache_shmcb.c
===
RCS file:
/mnt/david/debian/apache2/apache2-2.0.40/build-tree/cvs_cache/httpd-2.0.40/modules/ssl/ssl_scache_shmcb.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ssl_scache_shmcb.c
--- modules/ssl/ssl_scache_shmcb.c 17 Sep 2002 15:49:50 - 1.1.1.1
+++ modules/ssl/ssl_scache_shmcb.c 17 Sep 2002 19:54:26 -
@@ -385,7 +385,30 @@
}
shm_segment = apr_shm_baseaddr_get(mc-pSessionCacheDataMM);
shm_segsize = apr_shm_size_get(mc-pSessionCacheDataMM);
-
+/* We want the shared memory segment to go away as soon as the
+ * program exists. This is done by marking it as destroyed
+ * which also removes the name-based shared memory lookup key
+ * attach, which is fine since shm access is preserved accross
+ * fork calls. If the segment doesn't go away when we exit, we
+ * waste memory and can't restart since creating a memory
+ * segment that already exists fails.
+ */
+#if 1
+if(!apr_shm_mark_destroyed(mc-pSessionCacheDataMM))
+{
+ /* The worst thing we could do now is exit, since we know
+* the shared memory segment won't be cleaned up and
+* apache won't be able to start next time. Just hope
+* it will be properly cleaned up when apache gracefully
+* exits.
+*/
+char buf[100];
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ Cannot makr shared memory for destruction: (%d)%s, rv,
+ apr_strerror(rv, buf, sizeof(buf)));
+}
+#endif
+
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
shmcb_init allocated % APR_SIZE_T_FMT
bytes of shared memory,
Index: srclib/apr/include/apr_shm.h
===
RCS file:
/mnt/david/debian/apache2/apache2-2.0.40/build-tree/cvs_cache/httpd-2.0.40/srclib/apr/include/apr_shm.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 apr_shm.h
--- srclib/apr/include/apr_shm.h17 Sep 2002 15:49:58 - 1.1.1.1
+++ srclib/apr/include/apr_shm.h17 Sep 2002 19:54:57 -
@@ -109,6 +109,15 @@
apr_pool_t *pool);
/**
+ * Mark a shared memory segment for destruction when all
+ * processes detach from it. Currently this prevents
+ * processes from attaching, this could change if we
+ * kept track of the segment id.
+ * @param m The shared memory segment structure to mark for destruction.
+ */
+APR_DECLARE(apr_status_t) apr_shm_mark_destroyed(apr_shm_t *m);
+
+/**
* Destroy a shared memory segment and associated memory.
* @param m The shared memory segment structure to destroy.
*/
Index: srclib/apr/shmem/unix/shm.c
===
RCS file:
/mnt/david/debian/apache2/apache2-2.0.40/build-tree/cvs_cache/httpd-2.0.40/srclib/apr/shmem/unix/shm.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 shm.c
--- srclib/apr/shmem/unix/shm.c 17 Sep 2002 15:49:57 - 1.1.1.1
+++ srclib/apr/shmem/unix/shm.c 17 Sep 2002 19:57:10 -
@@ -109,11 +109,40 @@
/* Indicate that the segment is to be destroyed as soon
* as all processes have detached. This also disallows any
- * new attachments to the segment. */
+ * new attachments to the segment using the named based
+* lookup key, we could however use the shared memory id
+* and attach
Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memory cleanup]
On Wed, Sep 18, 2002 at 10:24:43AM +0100, Thom May wrote: ... please can the cc line ([EMAIL PROTECTED]) be maintained so the bug gets a record of this? Well, dunno about that. Since this list obeys Ken's nefarious insistence on Reply-To munging, who knows what'll happen when people reply? ducks :-) -- Greg Stein, http://www.lyra.org/
Re: (forw) [dfries@mail.win.org: Bug#161253: apache2: shared memorycleanup]
On Wed, 2002-09-18 at 19:24, Thom May wrote: Shared memory (as used by at least the ssl module) needs to rethink how they go about cleaning it up. Currently kill -9 the apache processes or it would appear that even /etc/init.d/apache2 reload will cause apache to fail to start because the shared memory segment can't be created since it already exists. I can confirm that. Given me a headache many times... Bojan
Re: cvs commit: httpd-2.0/build httpd_roll_release
On Tue, Sep 17, 2002 at 06:43:41PM -, [EMAIL PROTECTED] wrote: striker 2002/09/17 11:43:41 Modified:buildhttpd_roll_release Log: Fixup the timestamp on modules/ssl/ssl_expr_parse.c after running buildconf when we roll a release. The same has to be done for ssl_expr_parse.h and ssl_expr_scan.c also. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
WWW-Authenticate header lost when reverse-proxying chunked response
The WWW-Authenticate header is being dropped from responses sent by
mod_proxy in reverse proxy mode, when the original server's response
was chunked.
The problem appears to be in ap_http_header_filter() in
modules/http/http_protocol.c, where we have:
if (r-status == HTTP_NOT_MODIFIED) {
apr_table_do((int (*)(void *, const char *, const char *))
form_header_field,
(void *) h, r-headers_out,
Connection,
Keep-Alive,
ETag,
Content-Location,
Expires,
Cache-Control,
Vary,
Warning,
WWW-Authenticate,
Proxy-Authenticate,
NULL);
}
else {
apr_table_do((int (*) (void *, const char *, const char *))
form_header_field,
(void *) h, r-headers_out, NULL);
}
I would think that in the else case at least the WWW-Authenticate
header should be handled. Are there other headers that should also be
handled here?
Re: Seg fault in mod_dav.
More details. YAY First, a stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 18642)] 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762 1762if ((err = (*vsn_hooks-get_option)(resource, elem, body)) (gdb) where #0 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762 #1 0x403d3424 in dav_handler (r=0x8123470) at mod_dav.c:4507 #2 0x08064db8 in ap_run_handler (r=0x8123470) at config.c:194 #3 0x0806533d in ap_invoke_handler (r=0x8123470) at config.c:401 #4 0x080624c6 in ap_process_request (r=0x8123470) at http_request.c:288 #5 0x0805e28b in ap_process_http_connection (c=0x811d528) at http_core.c:293 #6 0x0806d138 in ap_run_process_connection (c=0x811d528) at connection.c:85 #7 0x0806d3e3 in ap_process_connection (c=0x811d528, csd=0x811d458) at connection.c:207 #8 0x08063a4a in child_main (child_num_arg=0) at prefork.c:696 #9 0x08063b08 in make_child (s=0x80996f0, slot=0) at prefork.c:736 #10 0x08063bfe in startup_children (number_to_start=5) at prefork.c:808 #11 0x08063f0c in ap_mpm_run (_pconf=0x8097950, plog=0x80c19f8, s=0x80996f0) at prefork.c:1024 #12 0x0806958c in main (argc=4, argv=0xbba4) at main.c:643 #13 0x402943c1 in __libc_start_main () from /lib/libc.so.6 Next, the value of vsn_hooks: gdb) p vsn_hooks $1 = (dav_hooks_vsn *) 0x0 Finally, the config and the problem: Location /svn/repos Dav svn SVNPath /svn # snipped for brevity, not the cuase /Location The problem is that I was requesting: svn import http://www.rkbloom.net/svn mumble Notice that the config is /svn/repos, but the command is /svn. There is no /svn, so I should have gotten a 404 back. Ryan On Wed, 18 Sep 2002, Greg Stein wrote: On Wed, Sep 18, 2002 at 06:49:48PM -0400, [EMAIL PROTECTED] wrote: I don't know if this is in .41 because I haven't had time to test it yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you send an OPTIONS request for a location that isn't configured for DAV, the module seg faults. I have traced it far enough to know where it is happening, but the fix shouldn't require that information. Basically, the mod_dav handler should be ensuring that Dav has been given a provider for the current location before it tries to handle the request. If this bug exists in 2.0.41, then -1 for GA. I will try to test .41 later tonight, and to create a patch at the same time. I'm not seeing that problem: [gstein@roshi test]$ telnet localhost 8080 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. OPTIONS /icons/ HTTP/1.0 host: roshi.collab.net HTTP/1.1 200 OK Date: Wed, 18 Sep 2002 23:26:28 GMT Server: Apache/2.0.41 (Unix) DAV/2 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Connection: close Content-Type: httpd/unix-directory Connection closed by foreign host. [gstein@roshi test]$ (I'm not sure that the above code is exactly 2.0.41, but something close) I'm updating to HEAD to check this out some more. Can you provide a backtrace for what you're seeing? Cheers, -g -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Problems checking out new module from newly setup SVN server
Well, I found my problem... APPARENTLY, SVN doesn't like the worker MPM... This is with Apache 2.0.41. I'm ccing httpd-dev in case it's an apache problem and not a svn problem. Note, even when I did an OPTIONS on /svn, it would freeze for a good 2 minutes or so. The backtrace I got when I ran httpd -X with GDB: #0 0x402a2bb5 in __sigsuspend (set=0xb7e0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x402686b8 in sigwait (set=0xb8b0, sig=0xb8ac) at signals.c:221 #2 0x401ea414 in apr_signal_thread (signal_handler=0x80aa164 check_signal) at signals.c:414 #3 0x080aa887 in child_main (child_num_arg=0) at worker.c:1277 #4 0x080aa986 in make_child (s=0x810e490, slot=0) at worker.c:1356 #5 0x080aaa6b in startup_children (number_to_start=2) at worker.c:1410 #6 0x080ab109 in ap_mpm_run (_pconf=0x80f6870, plog=0x8136970, s=0x810e490) at worker.c:1721 #7 0x080b0953 in main (argc=2, argv=0xbab4) at main.c:643 #8 0x40290657 in __libc_start_main (main=0x80b01e0 main, argc=2, ubp_av=0xbab4, init=0x8066284 _init, fini=0x80c63f0 _fini, rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xbaac) at ../sysdeps/generic/libc-start.c:129 On Wednesday 18 September 2002 05:26 pm, Jeff Stuart wrote: Ok, I installed SVN just like the docs say. Modified httpd.conf to create the /svn URL. I also created the repository AND imported a module. svn using the file URLs works perfectly. I've also restarted the server. When I try to check out the module using the HTTP URL, it fails. Here's what I get: (rjbtel@rjb2)()(05:15PM:09/18/02) (1252:252)$ svn co http://localhost/svn/banneroverdrive bo svn: RA layer request failed svn: PROPFIND of /: 405 Method Not Allowed and in the access log, I get this: 127.0.0.1 - - [18/Sep/2002:17:19:57 -0400] PROPFIND / HTTP/1.1 405 728 - neon/0.23.3 SVN/0.14. 2 (dev build) NOTHING at all in the error log... ANY ideas? -- Jeff Stuart [EMAIL PROTECTED]
[STATUS] (apache-1.3) Wed Sep 18 23:45:08 EDT 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/09/18 15:36:26 $] Release: 1.3.27-dev: In development. Jim proposes a t/r on or around Sept 24. 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
[STATUS] (httpd-2.0) Wed Sep 18 23:45:14 EDT 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/09/17 07:02:16 $] Release: 2.0.42 : in development. 2.0.41 : rolled September 16, 2002. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: rbb, striker ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken * Should we always build [support*] binaries statically unless otherwise indicated? Message-ID: [EMAIL PROTECTED] +1: Ken, *wrowe [they are PITAs on OSX] -1: Justin, Ian * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, Jim, Justin Have 2 parents: +1: Jim -1: Justin, wrowe [for 2.0] +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing) -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * All handlers should always send content down even if r-header_only is set. If not, it means that the HEAD requests don't generate the same headers as a GET which is wrong. Is this a showstopper? +1: Justin, Ken -1: Aaron * server pushed CGI's not working. (Is this a showstopper??) PR: 8482 Message-ID: [EMAIL PROTECTED] * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 Jeff: See my reply and patch in the PR (and previous commit to stop using pipe as a field name). If patch is committed, we should be okay. I'll wait to see if the user tests the patch. Update by Jeff 20020722: I got an account on HP 10.20. It looks like some of the APR thread detection is screwed up. If we find pthread.h but we can't compile the pthread test program we still think we can use threads. For that reason, the patch I posted to the PR won't work as-is since a failed compile of the test program means nothing. * exec cmd and suexec
[PATCH] DAV method registration
This patch moves all the DAV method registration into the mod_dav module
from the http core. I'd like to do this for a couple reasons:
1) It makes more sense to register these methods from the same module
they are used in.
2) Since Apache can only handle 62 registered methods, it doesn't make
sense to register these in the core even if the dav module isn't loaded.
(Other modules may need these slots in the method bitmask)
This does have the side-effect that method numbers looked up from DAV
will now come from the methods_registry hashtable, rather than the slightly
faster internal method lookup. However, I don't think the performance
difference between the two should be that great.
This patch also fixes a bug where DAV's BIND and SEARCH methods were being
registered with the core twice, since post_config gets called twice.
I have put in a check so that the methods only get registered once.
This passes the DAV litmus test (http://www.webdav.org/neon/litmus/), but
it could use some reviewing by people more familiar the module.
Comments?
-Ryan
Index: include/httpd.h
===
RCS file: /home/cvspublic/httpd-2.0/include/httpd.h,v
retrieving revision 1.189
diff -u -r1.189 httpd.h
--- include/httpd.h 1 Jul 2002 17:49:53 - 1.189
+++ include/httpd.h 19 Sep 2002 04:12:38 -
-529,27 +529,9
#define M_DELETE3
#define M_CONNECT 4
#define M_OPTIONS 5
-#define M_TRACE 6 /* RFC 2616: HTTP */
-#define M_PATCH 7 /* no rfc(!) ### remove this one? */
-#define M_PROPFIND 8 /* RFC 2518: WebDAV */
-#define M_PROPPATCH 9 /* : */
-#define M_MKCOL 10
-#define M_COPY 11
-#define M_MOVE 12
-#define M_LOCK 13
-#define M_UNLOCK14 /* RFC 2518: WebDAV */
-#define M_VERSION_CONTROL 15 /* RFC 3253: WebDAV Versioning */
-#define M_CHECKOUT 16 /* : */
-#define M_UNCHECKOUT17
-#define M_CHECKIN 18
-#define M_UPDATE19
-#define M_LABEL 20
-#define M_REPORT21
-#define M_MKWORKSPACE 22
-#define M_MKACTIVITY23
-#define M_BASELINE_CONTROL 24
-#define M_MERGE 25
-#define M_INVALID 26 /* RFC 3253: WebDAV Versioning */
+#define M_TRACE 6
+#define M_PATCH 7 /* RFC 2068: HTTP */
+#define M_INVALID 8 /* For un-implemented commands */
/**
* METHODS needs to be equal to the number of bits
Index: modules/dav/main/mod_dav.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/dav/main/mod_dav.c,v
retrieving revision 1.89
diff -u -r1.89 mod_dav.c
--- modules/dav/main/mod_dav.c 19 Sep 2002 02:36:08 - 1.89
+++ modules/dav/main/mod_dav.c 19 Sep 2002 04:12:51 -
-137,19 +137,68
enum {
DAV_M_BIND = 0,
DAV_M_SEARCH,
+DAV_M_PROPFIND,
+DAV_M_PROPPATCH,
+DAV_M_MKCOL,
+DAV_M_COPY,
+DAV_M_MOVE,
+DAV_M_LOCK,
+DAV_M_UNLOCK,
+DAV_M_VERSION_CONTROL,
+DAV_M_CHECKOUT,
+DAV_M_UNCHECKOUT,
+DAV_M_CHECKIN,
+DAV_M_UPDATE,
+DAV_M_LABEL,
+DAV_M_REPORT,
+DAV_M_MKWORKSPACE,
+DAV_M_MKACTIVITY,
+DAV_M_BASELINE_CONTROL,
+DAV_M_MERGE,
DAV_M_LAST
};
-static int dav_methods[DAV_M_LAST];
+static int dav_methods[DAV_M_LAST];
static int dav_init_handler(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp,
server_rec *s)
{
/* DBG0(dav_init_handler); */
+void *data;
+const char *dav_init_key = dav_init_handler;
+
+/* Only register the methods and add the version component on the
+ * second run of post_config */
+apr_pool_userdata_get(data, dav_init_key, s-process-pool);
+if (!data) {
+apr_pool_userdata_set((const void *)1, dav_init_key,
+ apr_pool_cleanup_null, s-process-pool);
+return OK;
+}
/* Register DAV methods */
dav_methods[DAV_M_BIND] = ap_method_register(p, BIND);
dav_methods[DAV_M_SEARCH] = ap_method_register(p, SEARCH);
+dav_methods[DAV_M_PROPFIND] = ap_method_register(p, PROPFIND);
+dav_methods[DAV_M_PROPPATCH] = ap_method_register(p, PROPPATCH);
+dav_methods[DAV_M_MKCOL] = ap_method_register(p, MKCOL);
+dav_methods[DAV_M_COPY] = ap_method_register(p, COPY);
+dav_methods[DAV_M_MOVE] = ap_method_register(p, MOVE);
+dav_methods[DAV_M_LOCK] = ap_method_register(p, LOCK);
+dav_methods[DAV_M_UNLOCK] = ap_method_register(p, UNLOCK);
+dav_methods[DAV_M_VERSION_CONTROL] =
+ap_method_register(p, VERSION-CONTROL);
+dav_methods[DAV_M_CHECKOUT] = ap_method_register(p, CHECKOUT);
+
[PATCH]: mod_log_config.c: FOR YOUR EYES ONLY :-)
I didn't even compile this baby, let alone test it, but I wanted to check with everyone if I'm finally moving in the right direction with this. Bojan PS. This is along the lines of what Ryan suggested, or at least I hope it is ;-) - This mail sent through IMP: http://horde.org/imp/ mod_log_config.c.patch Description: Binary data
ForceLanguagePriority in Apache 1.3
By the way, I love the idea of backporting the Apache 2.0 ForceLanguagePriority into Apache 1.3... This directive completely solves a looot of problems I've been having with stupid non-standards-conformant IE and content negotation. Many thanks to whoever posted the patch. If only it were possible that this could be included with 1.3.27 I'd be one very happy camper! ;o) Dave
Re: Seg fault in mod_dav.
On Wed, Sep 18, 2002 at 07:47:14PM -0700, Greg Stein wrote: Okay... I've checked in the change. I'd suggest tossing 2.0.41 and roll this fix into a 2.0.42. (I'm not suggesting using HEAD for 2.0.42) Something like: $ cvs tag -r APACHE_2_0_41 APACHE_2_0_42 # copy the tag $ cvs tag -F APACHE_2_0_42 modules/dav/main/mod_dav.c Then roll and release 2.0.42. Yeah, the only other gotcha I've seen with 2.0.41 is that the CHANGES file is wholly incorrect. Namely that the aaa rewrite isn't in .41. +1 for including the mod_dav fix and calling it 2.0.42. -- justin
