Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 92376 invoked by uid 500); 30 Dec 2001 17:27:58 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 92365 invoked by uid 500); 30 Dec 2001 17:27:58 -0000 Delivered-To: apmail-new-httpd@apache.org Errors-To: Message-ID: <016a01c19157$3eba3ee0$95c0b0d0@v505> From: "William A. Rowe, Jr." To: Subject: One more before .30? Date: Sun, 30 Dec 2001 11:25:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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