"William A. Rowe, Jr." wrote:
>
> The actual merge occurs in ap_sub_req_method_uri().
Thanks!
> Can you breakpoint and
> determine what's passed? This sounds like a vhost's per-dir-config may not
> be initialized.
from an earlier post,
#6 0x08081d1e in ap_sub_req_method_uri (method=0x8094501 "GET",
new_file=0x80da88c "index.html", r=0x81091c4, next_filter=0x0)
at request.c:1473
>
> I also (reviewing that code) didn't like what I saw...
>
> udir = ap_make_dirstr_parent(rnew->pool, r->uri);
> udir = ap_escape_uri(rnew->pool, udir); /* re-escape it */
> ap_parse_uri(rnew, ap_make_full_path(rnew->pool, udir, new_file));
>
> This means that the new_file is _never_ escaped!!!
>
> The code below might fit -some- situations better...
>
> udir = ap_make_dirstr_parent(rnew->pool, r->uri);
> udir = ap_make_full_path(rnew->pool, udir, new_file);
> udir = ap_escape_uri(rnew->pool, udir); /* re-escape it */
> ap_parse_uri(rnew, udir);
>
I can play with that and see if it helps. So ap_make_full_path should
do Good Stuff for me?
what I found in the mean time: the problem goes away if I disable
mod_rewrite. It has a translate hook that is setting the subrequest's
r->filename to "/index.html" (?huh?!?). r->canonical_filename remains
null. The core's translate phase backs off if it finds r->filename is
already set. When mod_rewrite is disabled (i.e. r->filename is null),
ap_core_translate calls apr_filepath_merge and everything works. With
or without mod_rewrite, the subrequest's r->filename is null when we get
to ap_process_request_internal.
Greg
