Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 43872 invoked by uid 500); 14 Apr 2003 04:11:24 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 43642 invoked from network); 14 Apr 2003 04:11:23 -0000 Received: from unknown (HELO mail.logilune.com) (195.154.174.52) by daedalus.apache.org with SMTP; 14 Apr 2003 04:11:23 -0000 Received: from stason.org (localhost.logilune.com [127.0.0.1]) by mail.logilune.com (Postfix) with ESMTP id A8FA77ACD5; Mon, 14 Apr 2003 06:11:30 +0200 (CEST) Message-ID: <3E9A34F5.1040303@stason.org> Date: Mon, 14 Apr 2003 14:11:33 +1000 From: Stas Bekman Organization: Hope, Humanized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Kobes Cc: Joe Schaefer , dev@perl.apache.org, apreq-dev@httpd.apache.org Subject: Re: [win32] Locations in Apache-Test framework References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Randy Kobes wrote: > On Mon, 14 Apr 2003, Stas Bekman wrote: > > >>Randy Kobes wrote: >> >>>On Mon, 14 Apr 2003, Stas Bekman wrote: >>> >>>[ .. ] >>> >>> >>>>Randy, what happens if you configure some valid virtual >>>>resource as foo::bar (outside of Apache::Test) and try >>>>accessing it? Do you get 403? >>> >>>Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a >>>working >>> >>> SetHandler perl-script >>> PerlHandler Apache::Hello >>> >>>(PerlResponseHandler for modperl 2) generates a 403 by simply >>>changing this to, eg, . For some reason the >>>modperl 2 tests don't run into this problem - I'll try to see >>>why. >> >>Could it be due to this handler, running for all requests? >> >>PerlTransHandler TestHooks::trans >> >>May be after calling $r->uri, Apache initializes some data structure, which >>doesn't cause a latter problem? > > > You're good at this stuff :) Commenting out the PerlTransHandler > in httpd.conf in the mod_perl 2 tests does lead to the 403 errors > in tests that successfully run with PerlTransHandler. I was just looking for something odd that mp2 test suite does ;) >>>Actually, again on both 1.3.x and 2.0.45, making a request for >>>http://localhost/foo::bar (where foo::bar doesn't appear in a >>>) generates a 403, rather than a 404. >> >>Randy, can you please run this by httpd-dev? This doesn't seem right. >> >>(Certainly we still want to be able to run tests on winFU, but let's first >>figure out why this thing happens). > > I'll do that - I looked for a bug report for this earlier, but > couldn't find one. And just in case it was some quirk of my > system, I tried this on f3.freespace.jp, which netcraft reports > as running Apache/1.3.27 on Win32 - a request there for > some (presumably) non-existent thing results in a 403 if > that thing has a ':' in it. Somebody will probably have a reason why ':' is invalid in uri path ;) So, we are stuck with the current situation no matter what would be the outcome of this issue. Randy suggests to s/::/-/. Any other suggestions? I thought it'd be nicer to s|::|/| so it better maps to the file, but it's probably a bad idea for possible overlaps of handlers within the same top-level namespace (error-prone). Unless somebody thinks that s/::/-/ is not good enough we will go with this change. Of course we could also automatically add this handler to the autogenerated httpd.conf ;) PerlTransHandler TestHooks::trans "sub handler {shift->uri; return Apache::DECLINED}" __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com