Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 28658 invoked by uid 6000); 7 Jun 1998 11:20:08 -0000 Received: (qmail 28644 invoked from network); 7 Jun 1998 11:20:05 -0000 Received: from eastwood.aldigital.algroup.co.uk (194.128.162.193) by taz.hyperreal.org with SMTP; 7 Jun 1998 11:20:05 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id LAA07719; Sun, 7 Jun 1998 11:19:12 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA12302; Sun, 7 Jun 1998 12:19:24 +0100 Message-ID: <357A7730.EA090060@algroup.co.uk> Date: Sun, 07 Jun 1998 12:19:12 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: new-httpd@apache.org CC: modperl@apache.org Subject: Re: Path info References: <199806050244.WAA23461@postman.opengroup.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Doug MacEachern wrote: > > "Jeffrey W. Baker" wrote: > > > At 08:56 PM 6/3/98 -0700, you wrote: > > > > >We're looking not to hold session-type data in the path info. Our need is > > >totally separate from the need for holding session information. Rather, our > > >need is to encode more literal path-style information, where there are many > > >'areas' within a single 'directory' handled by Perl*Handler (in this case, > > >/uptime). > > > > > > /uptime/UPT::Contact/23443/edit > > > /uptime/UPT::Client/987/add_new_Job > > > /uptime/UPT::Job_Item/42333/4/edit > > > > > >(perhaps with session id's added to those paths too!) > > > > > >These allow access to a database, with primary key values and desired output > > >formats being specified in that path information. > > > > Also note that path_info functionality on Win32 Apache is severly broken. > > In 1.3b5/6, a trailing slash or a double slash in the path info is stripped > > out when calling $r->path_info, but not when calling $r->uri, so acquiring > > the true URI via length($r->path_info) doesn't work. On 1.3b7, any slash > > in the path info causes a 404 Not Found error. I filed a bug but I guess I > > should have marked it as critical, as I haven't heard back from anybody. > > I'm not sure what's going on here, but CHANGES for 1.3b6 has this: > > *) WIN32: Preserve trailing slash in canonical path (and hence > in PATH_INFO). [Paul Sutton, Ben Laurie] > > CC'd to new-httpd, maybe Paul or Ben could shed some light? The short answer is that path info does seem to be screwed by filename canonicalisation. I believe someone is working on it. Cheers, Ben. -- Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: ben@algroup.co.uk | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/