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
