httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [win32] Locations in Apache-Test framework
Date Mon, 14 Apr 2003 04:11:33 GMT
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
>>>  <Location /hello>
>>>    SetHandler perl-script
>>>    PerlHandler Apache::Hello
>>>  </Location>
>>>(PerlResponseHandler for modperl 2) generates a 403 by simply
>>>changing this to, eg, <Location /hel::lo>. 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
>>><Location>) 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


Mime
View raw message