One more before .30?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

There are still issues with PATH_INFO/QUERY_STRING on redirected
(multiviewed) ap_lookup_sub_req_dirent CGI's that I'd like to
tackle.  It may be an API change, so the sooner the better.

The lookup file/dirent schema is really cool, except that it 
doesn't give us a graceful point to insert the parent request's
path_info/args, and even if it did, we don't want to do so in
an all-or-nothing manner.

For example, with autoindex, we aren't going to give them the
query args from the autoindex listing options.  For negotiation,
we certainly need to.  Likewise for path_info, we need it in
negotation, but do we want it when the user does an SSI include
file?  No.

This was very simple to solve for mod_dir, since the DirectoryIndex
list are URIs [that may be outside the current directory].  It was
simple to merge.  [There is an optimization case that covers the
same territory, however, where it's a relative lookup in the same
directory, and contains no slashes.]

But we don't need to waste the time concatinating and resplitting
the path_info.  Since negotation looks at files only, and we have
a bit of optimized code in dir_walk that allows us preexisting
path_info, I'm picturing a flag to the lookup functions to let them 
do all the work required, such as CARRY_PATH_INFO, CARRY_ARGS, etc.
This schema can be extended later, if we realize lookups aught to
do other things.

Does this flag make sense to everyone, or should we make them carry
out the work in their own code?  I'd also probably export the 
make_sub_request code, since it's so danged useful we use it for 
all three variants (uri, file and dirent) and module authors could 
easily derive their own subrequest flavors, consistantly.

Bill