AFAICT, there is only one remaining showstopper problem with 2.0.26-dev,
which is that subrequests for relative paths in other directories (ones
that result in r->uri being that "INTERNALLY GENERATED" thing) often cause
a segfault (mod_include exhibits this problem when doing includes of files
in subdirectories, for example). The hack below disables the "INTERNALLY
GENERATED" thing, which eliminates the segfault. I figure that's okay
since the block of code in question is already hacked with a bunch of #if
0's pending a re-evaluation of how we handle these code paths for
subrequests. With the patch below, the server survives everything I've
managed to throw at it. If no one objects, I'll apply this for now so we
can at least have something fairly stable to play with and hopefully get
2.0.26 nailed down. Any comments? Are there any other problems of which
I'm unaware? Jerry, is that problem you were seeing in 2.0.25 fixed in
2.0.26-dev?
--Cliff
Index: request.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.43
diff -u -d -r1.43 request.c
--- request.c 2001/08/31 10:58:47 1.43
+++ request.c 2001/08/31 18:38:32
@@ -1567,9 +1567,11 @@
* either, if the base paths match, we can pick up where we leave off.
*/
+#if 0
if (strncmp(rnew->filename, fdir, fdirlen) == 0
&& rnew->filename[fdirlen]
&& ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
+#endif
{
char *udir = ap_make_dirstr_parent(rnew->pool, r->uri);
@@ -1646,7 +1648,6 @@
r->filename);
res = HTTP_FORBIDDEN;
}
-#endif
}
else {
/* XXX: @@@: What should be done with the parsed_uri values? */
@@ -1658,7 +1659,7 @@
*/
rnew->uri = "INTERNALLY GENERATED file-relative req";
-#if 0 /* XXX When this is reenabled, the cache triggers need to be set to faux
+ /* XXX When this is reenabled, the cache triggers need to be set to faux
* dir_walk/file_walk values.
*/
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
