Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 91301 invoked by uid 500); 17 Sep 2001 06:19:32 -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 91290 invoked from network); 17 Sep 2001 06:19:32 -0000 Errors-To: Message-ID: <09a401c13f40$48ec5830$93c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: References: Subject: Null r->uri? Date: Mon, 17 Sep 2001 01:16:24 -0500 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.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Cliff Woolley" Sent: Monday, September 17, 2001 12:05 AM > It did up until about two weeks ago, but then that was because r->uri was > set to a completely bogus value (the string "INTERNALLY GENERATED > file-relative req" or something like that), rather than just "". =-) I > don't think r->uri can be actually NULL, though (somebody correct me if > I'm wrong). We haven't decided what should become of r->uri in a relative file lookup yet, have we? I'd suggest the undecorated (relative) file name itself, e.g. "file.foo". Clearly invalid (it's relative) yet protective (it hits all tests except , and other applications interested in r->uri won't be overly confused). We can set an apr_pool_userdata element to flag that it is a legitimate exception, and filter those out again later in the request parsing. Bill