You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2003/04/14 02:59:29 UTC
[win32] Locations in Apache-Test framework
In trying to run the tests under Win32 in httpd-apreq (which are
being converted over to use the Apache-Test framework), I ran
into something. At present, under certain conditions some
<Location > directives will be automatically generated like
<Location /TestApReq::inherit>
SetHandler perl-script
PerlHandler TestApReq::inherit
</Location>
Such tests in httpd-apreq generate 403 errors, I think because on
Win32 colons are invalid in filenames - manually changing the
location to, eg, TestApReq-inherit, and adjusting the request in
the corresponding .t file accordingly, gets rid of this error. I
checked this also happens in my "real" Apache configuration (both
1 and 2) - simply changing a working <Location> directive (not
corresponding to any physical file) to having a colon in the name
generates an error.
This problem seems subtle ... For one thing, the mod_perl 2 tests
use this <Location> convention with colons, and they work on
Win32. So this can be made to work, somehow. Also, I would have
thought <Location> directives would be checked even before
filenames - for example, a <Location /hello> takes precedence
over a physical file @@DocumentRoot@@/hello. But perhaps, for the
purposes of Apache-Test, these subtelties may be academic - since
the httpd-apreq tests seem OK, and might be something that a
typical user might generate, it might save some problems in the
future to change the <Location> directives to use, eg, '-' rather
than '::' in the names?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
>
> Have you overridden the map_to_storage hook?
As Randy replied he sees the same problem with both versions. It also seems to
be non-specific to mod_perl.
The problem disappears if we supply ap_hook_translate_name which sets r->filename.
#XXX: temp workaround, core_translate trips on :'s
if (Apache::TestConfig::WIN32()) {
if ($uri =~ m,^/Test[A-Z]\w+::,) {
$r->filename(__FILE__);
return Apache::OK;
}
}
But this is not a proper solution.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
>
> Have you overridden the map_to_storage hook?
As Randy replied he sees the same problem with both versions. It also seems to
be non-specific to mod_perl.
The problem disappears if we supply ap_hook_translate_name which sets r->filename.
#XXX: temp workaround, core_translate trips on :'s
if (Apache::TestConfig::WIN32()) {
if ($uri =~ m,^/Test[A-Z]\w+::,) {
$r->filename(__FILE__);
return Apache::OK;
}
}
But this is not a proper solution.
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
The general issue of ':' in locations happens in both 1.3 and
2.0.
>
> Have you overridden the map_to_storage hook? Several modules
> hook map_to storage; mod_proxy (FIRST) looks for any URI that
> is in proxy space - and sums up the <Proxy > sections for that
> URI, the core (MIDDLE) finds the TRACE requests and finishes
> them up already (nothing more to-do about TRACE after Proxy had
> a chance) and finally VERY_LAST (should have been simply LAST)
> we try the <Directory > and <File > request paths.
>
> It doesn't sound like you are looking at real files, which
> make <Directory > and <Files > sections sort of silly. And
> prone to confusion.
That's right that this wasn't with real files, just virtual
locations. For example, a working location
<Location /hello>
# some directives
</Location>
gives a 403 with the simple change
<Location /hell::o>
# same directives as above
</Location>
but
<Location /hello/hell::o>
# same directives as above
</Location>
works. This is with no physical directory "/hello"
within DocumentRoot.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
The general issue of ':' in locations happens in both 1.3 and
2.0.
>
> Have you overridden the map_to_storage hook? Several modules
> hook map_to storage; mod_proxy (FIRST) looks for any URI that
> is in proxy space - and sums up the <Proxy > sections for that
> URI, the core (MIDDLE) finds the TRACE requests and finishes
> them up already (nothing more to-do about TRACE after Proxy had
> a chance) and finally VERY_LAST (should have been simply LAST)
> we try the <Directory > and <File > request paths.
>
> It doesn't sound like you are looking at real files, which
> make <Directory > and <Files > sections sort of silly. And
> prone to confusion.
That's right that this wasn't with real files, just virtual
locations. For example, a working location
<Location /hello>
# some directives
</Location>
gives a 403 with the simple change
<Location /hell::o>
# same directives as above
</Location>
but
<Location /hello/hell::o>
# same directives as above
</Location>
works. This is with no physical directory "/hello"
within DocumentRoot.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Two fast questions;
Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
Have you overridden the map_to_storage hook? Several modules
hook map_to storage; mod_proxy (FIRST) looks for any URI that is
in proxy space - and sums up the <Proxy > sections for that URI,
the core (MIDDLE) finds the TRACE requests and finishes them up
already (nothing more to-do about TRACE after Proxy had a chance)
and finally VERY_LAST (should have been simply LAST) we try the
<Directory > and <File > request paths.
It doesn't sound like you are looking at real files, which make
<Directory > and <Files > sections sort of silly. And prone to confusion.
Try putting a map_to_storage hook MIDDLE-1 or LAST + 1 - and return
OK if translate_name phase picked up this request as it's own. Otherwise
continue to fall through to <Directory > and <Files > walks.
Note that <Location > happens both before and after map_to_storage.
Nobody can modify those phases in map_to_storage
Bill
At 11:50 PM 4/13/2003, Randy Kobes wrote:
>On 14 Apr 2003, Joe Schaefer wrote:
>
>> I'd bet apache is just returning a 403 for security purposes,
>> since ':' is what separates the drive letter from the file path
>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>> full answer, so you might want to take this issue up on
>> dev@httpd.
>
>That looks like it's probably it - there's some discussions in
>the httpd-dev list that were along these lines. Further to this,
>a location like
> <Location /hello/hell::o>
> ....
> </Location>
>does work - what might be happening is Win32 Apache is rejecting,
>via the 403, anything that looks like a leading drive
>designation, for security purposes.
>
>So it's probably easier to just s!::!-! or s!::!/!, as
>Stas proposed ...
>
>--
>best regards,
>randy
Re: [win32] Locations in Apache-Test framework
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Two fast questions;
Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
Have you overridden the map_to_storage hook? Several modules
hook map_to storage; mod_proxy (FIRST) looks for any URI that is
in proxy space - and sums up the <Proxy > sections for that URI,
the core (MIDDLE) finds the TRACE requests and finishes them up
already (nothing more to-do about TRACE after Proxy had a chance)
and finally VERY_LAST (should have been simply LAST) we try the
<Directory > and <File > request paths.
It doesn't sound like you are looking at real files, which make
<Directory > and <Files > sections sort of silly. And prone to confusion.
Try putting a map_to_storage hook MIDDLE-1 or LAST + 1 - and return
OK if translate_name phase picked up this request as it's own. Otherwise
continue to fall through to <Directory > and <Files > walks.
Note that <Location > happens both before and after map_to_storage.
Nobody can modify those phases in map_to_storage
Bill
At 11:50 PM 4/13/2003, Randy Kobes wrote:
>On 14 Apr 2003, Joe Schaefer wrote:
>
>> I'd bet apache is just returning a 403 for security purposes,
>> since ':' is what separates the drive letter from the file path
>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>> full answer, so you might want to take this issue up on
>> dev@httpd.
>
>That looks like it's probably it - there's some discussions in
>the httpd-dev list that were along these lines. Further to this,
>a location like
> <Location /hello/hell::o>
> ....
> </Location>
>does work - what might be happening is Win32 Apache is rejecting,
>via the 403, anything that looks like a leading drive
>designation, for security purposes.
>
>So it's probably easier to just s!::!-! or s!::!/!, as
>Stas proposed ...
>
>--
>best regards,
>randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Fri, 18 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Stas Bekman wrote:
>>>
>>>> Randy Kobes wrote:
>>>>
>>>>
>>>>> On 14 Apr 2003, Joe Schaefer wrote:
>>>>>
>>>>>
>>>>>> I'd bet apache is just returning a 403 for security purposes,
>>>>>> since ':' is what separates the drive letter from the file path
>>>>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>> full answer, so you might want to take this issue up on
>>>>>> dev@httpd.
>>>>>
>>>>>
>>>>> That looks like it's probably it - there's some discussions in
>>>>> the httpd-dev list that were along these lines. Further to this,
>>>>> a location like
>>>>> <Location /hello/hell::o>
>>>>> ....
>>>>> </Location>
>>>>> does work - what might be happening is Win32 Apache is rejecting,
>>>>> via the 403, anything that looks like a leading drive designation,
>>>>> for security purposes.
>>>>
>>>>
>>>> Hmm, is this valid at all on winFU to supply a drive: entry in the
>>>> URI path? I wonder why Apache can't reject paths with : in the first
>>>> segment only if virtual mapping have failed.
>>>>
>>>>
>>>>> So it's probably easier to just s!::!-! or s!::!/!, as
>>>>> Stas proposed ...
>>>>
>>>>
>>>> I think that even though <Location Foo/Bar> is more intuitive,
>>>> <Location Foo-Bar> is less error-prone.
>>>>
>>>> I think <Location Foo/Bar> is potentially error-prone, since if one
>>>> of the test package is 'Foo' we will have a location <Location Foo>
>>>> and then we will get merging with <Location Foo/Bar> something that
>>>> could be undesired.
>>>
>>>
>>> I think that at the end I'm simply going to install a default
>>> TransHandler, semi-transparent to the developer (put it into
>>> the autogenerated httpd.conf), rather than change the URLs.
>>
>>
>>
>> That's certainly the most straightforward thing to do, and less
>> subject to introducing new bugs. One downside though is that if
>> people use the mod_perl tests as a basis for their own
>> installations (which, given the extensive nature, is a wonderful
>> source of examples), they might not realize that it's this
>> TransHandler that makes such locations with ':' in their names
>> work on Win32. And getting 403s isn't the most intuitive error to
>> track down ....
>>
>> I'd be willing to go through the mod_perl 2 tests and track
>> the changes needed to s/::/-/, if that'd be useful ....
>
>
> Thank you, Randy!
>
> Doug suggests to rename as well, though to do it similar to XS naming
> convention so we would do s/::/__/.
>
> I'll take care of the renaming.
>
> I'll also remove the workaround afterwards.
>
> Joe, that means that apreq tests need to be updated as well.
Joe, this is the patch that needs to be applied after you 'cvs up' your
Apache-Test dir. I didn't commit it since I can't test it at this moment,
because I can't build httpd-apreq (will look at it later)
Index: t/apreq/big_input.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/big_input.t,v
retrieving revision 1.1
diff -u -r1.1 big_input.t
--- t/apreq/big_input.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/big_input.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
use Apache::TestUtil;
use Apache::TestRequest qw(GET_BODY POST_BODY);
-my $location = "/TestApReq::big_input";
+my $location = "/TestApReq__big_input";
my @key_len = (5, 100, 305);
my @key_num = (5, 15, 26);
Index: t/apreq/cookie.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/cookie.t,v
retrieving revision 1.1
diff -u -r1.1 cookie.t
--- t/apreq/cookie.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/cookie.t 18 Apr 2003 06:26:24 -0000
@@ -9,7 +9,7 @@
plan tests => 1;
-my $location = "/TestApReq::cookie";
+my $location = "/TestApReq__cookie";
{
# basic param() test
Index: t/apreq/inherit.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/inherit.t,v
retrieving revision 1.1
diff -u -r1.1 inherit.t
--- t/apreq/inherit.t 5 Apr 2003 23:29:37 -0000 1.1
+++ t/apreq/inherit.t 18 Apr 2003 06:26:24 -0000
@@ -7,7 +7,7 @@
use Apache::TestRequest qw(GET_BODY UPLOAD_BODY);
plan tests => 1;
-my $location = "/TestApReq::inherit";
+my $location = "/TestApReq__inherit";
ok t_cmp(<< 'VALUE', GET_BODY($location), "inheritance");
method => GET
VALUE
Index: t/apreq/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/request.t,v
retrieving revision 1.1
diff -u -r1.1 request.t
--- t/apreq/request.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/request.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
plan tests => 2;
-my $location = "/TestApReq::request";
+my $location = "/TestApReq__request";
#print GET_BODY $location;
{
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Fri, 18 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Stas Bekman wrote:
>>>
>>>> Randy Kobes wrote:
>>>>
>>>>
>>>>> On 14 Apr 2003, Joe Schaefer wrote:
>>>>>
>>>>>
>>>>>> I'd bet apache is just returning a 403 for security purposes,
>>>>>> since ':' is what separates the drive letter from the file path
>>>>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>> full answer, so you might want to take this issue up on
>>>>>> dev@httpd.
>>>>>
>>>>>
>>>>> That looks like it's probably it - there's some discussions in
>>>>> the httpd-dev list that were along these lines. Further to this,
>>>>> a location like
>>>>> <Location /hello/hell::o>
>>>>> ....
>>>>> </Location>
>>>>> does work - what might be happening is Win32 Apache is rejecting,
>>>>> via the 403, anything that looks like a leading drive designation,
>>>>> for security purposes.
>>>>
>>>>
>>>> Hmm, is this valid at all on winFU to supply a drive: entry in the
>>>> URI path? I wonder why Apache can't reject paths with : in the first
>>>> segment only if virtual mapping have failed.
>>>>
>>>>
>>>>> So it's probably easier to just s!::!-! or s!::!/!, as
>>>>> Stas proposed ...
>>>>
>>>>
>>>> I think that even though <Location Foo/Bar> is more intuitive,
>>>> <Location Foo-Bar> is less error-prone.
>>>>
>>>> I think <Location Foo/Bar> is potentially error-prone, since if one
>>>> of the test package is 'Foo' we will have a location <Location Foo>
>>>> and then we will get merging with <Location Foo/Bar> something that
>>>> could be undesired.
>>>
>>>
>>> I think that at the end I'm simply going to install a default
>>> TransHandler, semi-transparent to the developer (put it into
>>> the autogenerated httpd.conf), rather than change the URLs.
>>
>>
>>
>> That's certainly the most straightforward thing to do, and less
>> subject to introducing new bugs. One downside though is that if
>> people use the mod_perl tests as a basis for their own
>> installations (which, given the extensive nature, is a wonderful
>> source of examples), they might not realize that it's this
>> TransHandler that makes such locations with ':' in their names
>> work on Win32. And getting 403s isn't the most intuitive error to
>> track down ....
>>
>> I'd be willing to go through the mod_perl 2 tests and track
>> the changes needed to s/::/-/, if that'd be useful ....
>
>
> Thank you, Randy!
>
> Doug suggests to rename as well, though to do it similar to XS naming
> convention so we would do s/::/__/.
>
> I'll take care of the renaming.
>
> I'll also remove the workaround afterwards.
>
> Joe, that means that apreq tests need to be updated as well.
Joe, this is the patch that needs to be applied after you 'cvs up' your
Apache-Test dir. I didn't commit it since I can't test it at this moment,
because I can't build httpd-apreq (will look at it later)
Index: t/apreq/big_input.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/big_input.t,v
retrieving revision 1.1
diff -u -r1.1 big_input.t
--- t/apreq/big_input.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/big_input.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
use Apache::TestUtil;
use Apache::TestRequest qw(GET_BODY POST_BODY);
-my $location = "/TestApReq::big_input";
+my $location = "/TestApReq__big_input";
my @key_len = (5, 100, 305);
my @key_num = (5, 15, 26);
Index: t/apreq/cookie.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/cookie.t,v
retrieving revision 1.1
diff -u -r1.1 cookie.t
--- t/apreq/cookie.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/cookie.t 18 Apr 2003 06:26:24 -0000
@@ -9,7 +9,7 @@
plan tests => 1;
-my $location = "/TestApReq::cookie";
+my $location = "/TestApReq__cookie";
{
# basic param() test
Index: t/apreq/inherit.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/inherit.t,v
retrieving revision 1.1
diff -u -r1.1 inherit.t
--- t/apreq/inherit.t 5 Apr 2003 23:29:37 -0000 1.1
+++ t/apreq/inherit.t 18 Apr 2003 06:26:24 -0000
@@ -7,7 +7,7 @@
use Apache::TestRequest qw(GET_BODY UPLOAD_BODY);
plan tests => 1;
-my $location = "/TestApReq::inherit";
+my $location = "/TestApReq__inherit";
ok t_cmp(<< 'VALUE', GET_BODY($location), "inheritance");
method => GET
VALUE
Index: t/apreq/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/request.t,v
retrieving revision 1.1
diff -u -r1.1 request.t
--- t/apreq/request.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/request.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
plan tests => 2;
-my $location = "/TestApReq::request";
+my $location = "/TestApReq__request";
#print GET_BODY $location;
{
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 18 Apr 2003, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Randy Kobes wrote:
>>>
>>>
>>>>On 14 Apr 2003, Joe Schaefer wrote:
>>>>
>>>>
>>>>>I'd bet apache is just returning a 403 for security purposes,
>>>>>since ':' is what separates the drive letter from the file path
>>>>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>full answer, so you might want to take this issue up on
>>>>>dev@httpd.
>>>>
>>>>That looks like it's probably it - there's some discussions in
>>>>the httpd-dev list that were along these lines. Further to this,
>>>>a location like
>>>> <Location /hello/hell::o>
>>>> ....
>>>> </Location>
>>>>does work - what might be happening is Win32 Apache is rejecting,
>>>>via the 403, anything that looks like a leading drive designation, for
>>>>security purposes.
>>>
>>>Hmm, is this valid at all on winFU to supply a drive: entry in the URI
>>>path? I wonder why Apache can't reject paths with : in the first segment
>>>only if virtual mapping have failed.
>>>
>>>
>>>>So it's probably easier to just s!::!-! or s!::!/!, as
>>>>Stas proposed ...
>>>
>>>I think that even though <Location Foo/Bar> is more intuitive,
>>><Location Foo-Bar> is less error-prone.
>>>
>>>I think <Location Foo/Bar> is potentially error-prone, since if one of
>>>the test package is 'Foo' we will have a location <Location Foo> and
>>>then we will get merging with <Location Foo/Bar> something that could be
>>>undesired.
>>
>>I think that at the end I'm simply going to install a default
>>TransHandler, semi-transparent to the developer (put it into
>>the autogenerated httpd.conf), rather than change the URLs.
>
>
> That's certainly the most straightforward thing to do, and less
> subject to introducing new bugs. One downside though is that if
> people use the mod_perl tests as a basis for their own
> installations (which, given the extensive nature, is a wonderful
> source of examples), they might not realize that it's this
> TransHandler that makes such locations with ':' in their names
> work on Win32. And getting 403s isn't the most intuitive error to
> track down ....
>
> I'd be willing to go through the mod_perl 2 tests and track
> the changes needed to s/::/-/, if that'd be useful ....
Thank you, Randy!
Doug suggests to rename as well, though to do it similar to XS naming
convention so we would do s/::/__/.
I'll take care of the renaming.
I'll also remove the workaround afterwards.
Joe, that means that apreq tests need to be updated as well.
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 18 Apr 2003, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Randy Kobes wrote:
>>>
>>>
>>>>On 14 Apr 2003, Joe Schaefer wrote:
>>>>
>>>>
>>>>>I'd bet apache is just returning a 403 for security purposes,
>>>>>since ':' is what separates the drive letter from the file path
>>>>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>full answer, so you might want to take this issue up on
>>>>>dev@httpd.
>>>>
>>>>That looks like it's probably it - there's some discussions in
>>>>the httpd-dev list that were along these lines. Further to this,
>>>>a location like
>>>> <Location /hello/hell::o>
>>>> ....
>>>> </Location>
>>>>does work - what might be happening is Win32 Apache is rejecting,
>>>>via the 403, anything that looks like a leading drive designation, for
>>>>security purposes.
>>>
>>>Hmm, is this valid at all on winFU to supply a drive: entry in the URI
>>>path? I wonder why Apache can't reject paths with : in the first segment
>>>only if virtual mapping have failed.
>>>
>>>
>>>>So it's probably easier to just s!::!-! or s!::!/!, as
>>>>Stas proposed ...
>>>
>>>I think that even though <Location Foo/Bar> is more intuitive,
>>><Location Foo-Bar> is less error-prone.
>>>
>>>I think <Location Foo/Bar> is potentially error-prone, since if one of
>>>the test package is 'Foo' we will have a location <Location Foo> and
>>>then we will get merging with <Location Foo/Bar> something that could be
>>>undesired.
>>
>>I think that at the end I'm simply going to install a default
>>TransHandler, semi-transparent to the developer (put it into
>>the autogenerated httpd.conf), rather than change the URLs.
>
>
> That's certainly the most straightforward thing to do, and less
> subject to introducing new bugs. One downside though is that if
> people use the mod_perl tests as a basis for their own
> installations (which, given the extensive nature, is a wonderful
> source of examples), they might not realize that it's this
> TransHandler that makes such locations with ':' in their names
> work on Win32. And getting 403s isn't the most intuitive error to
> track down ....
>
> I'd be willing to go through the mod_perl 2 tests and track
> the changes needed to s/::/-/, if that'd be useful ....
Thank you, Randy!
Doug suggests to rename as well, though to do it similar to XS naming
convention so we would do s/::/__/.
I'll take care of the renaming.
I'll also remove the workaround afterwards.
Joe, that means that apreq tests need to be updated as well.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 18 Apr 2003, Stas Bekman wrote:
> Stas Bekman wrote:
> > Randy Kobes wrote:
> >
> >> On 14 Apr 2003, Joe Schaefer wrote:
> >>
> >>> I'd bet apache is just returning a 403 for security purposes,
> >>> since ':' is what separates the drive letter from the file path
> >>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> >>> full answer, so you might want to take this issue up on
> >>> dev@httpd.
> >>
> >> That looks like it's probably it - there's some discussions in
> >> the httpd-dev list that were along these lines. Further to this,
> >> a location like
> >> <Location /hello/hell::o>
> >> ....
> >> </Location>
> >> does work - what might be happening is Win32 Apache is rejecting,
> >> via the 403, anything that looks like a leading drive designation, for
> >> security purposes.
> >
> > Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> > path? I wonder why Apache can't reject paths with : in the first segment
> > only if virtual mapping have failed.
> >
> >> So it's probably easier to just s!::!-! or s!::!/!, as
> >> Stas proposed ...
> >
> > I think that even though <Location Foo/Bar> is more intuitive,
> > <Location Foo-Bar> is less error-prone.
> >
> > I think <Location Foo/Bar> is potentially error-prone, since if one of
> > the test package is 'Foo' we will have a location <Location Foo> and
> > then we will get merging with <Location Foo/Bar> something that could be
> > undesired.
>
> I think that at the end I'm simply going to install a default
> TransHandler, semi-transparent to the developer (put it into
> the autogenerated httpd.conf), rather than change the URLs.
That's certainly the most straightforward thing to do, and less
subject to introducing new bugs. One downside though is that if
people use the mod_perl tests as a basis for their own
installations (which, given the extensive nature, is a wonderful
source of examples), they might not realize that it's this
TransHandler that makes such locations with ':' in their names
work on Win32. And getting 403s isn't the most intuitive error to
track down ....
I'd be willing to go through the mod_perl 2 tests and track
the changes needed to s/::/-/, if that'd be useful ....
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 18 Apr 2003, Stas Bekman wrote:
> Stas Bekman wrote:
> > Randy Kobes wrote:
> >
> >> On 14 Apr 2003, Joe Schaefer wrote:
> >>
> >>> I'd bet apache is just returning a 403 for security purposes,
> >>> since ':' is what separates the drive letter from the file path
> >>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> >>> full answer, so you might want to take this issue up on
> >>> dev@httpd.
> >>
> >> That looks like it's probably it - there's some discussions in
> >> the httpd-dev list that were along these lines. Further to this,
> >> a location like
> >> <Location /hello/hell::o>
> >> ....
> >> </Location>
> >> does work - what might be happening is Win32 Apache is rejecting,
> >> via the 403, anything that looks like a leading drive designation, for
> >> security purposes.
> >
> > Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> > path? I wonder why Apache can't reject paths with : in the first segment
> > only if virtual mapping have failed.
> >
> >> So it's probably easier to just s!::!-! or s!::!/!, as
> >> Stas proposed ...
> >
> > I think that even though <Location Foo/Bar> is more intuitive,
> > <Location Foo-Bar> is less error-prone.
> >
> > I think <Location Foo/Bar> is potentially error-prone, since if one of
> > the test package is 'Foo' we will have a location <Location Foo> and
> > then we will get merging with <Location Foo/Bar> something that could be
> > undesired.
>
> I think that at the end I'm simply going to install a default
> TransHandler, semi-transparent to the developer (put it into
> the autogenerated httpd.conf), rather than change the URLs.
That's certainly the most straightforward thing to do, and less
subject to introducing new bugs. One downside though is that if
people use the mod_perl tests as a basis for their own
installations (which, given the extensive nature, is a wonderful
source of examples), they might not realize that it's this
TransHandler that makes such locations with ':' in their names
work on Win32. And getting 403s isn't the most intuitive error to
track down ....
I'd be willing to go through the mod_perl 2 tests and track
the changes needed to s/::/-/, if that'd be useful ....
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On 14 Apr 2003, Joe Schaefer wrote:
>>
>>
>>> I'd bet apache is just returning a 403 for security purposes,
>>> since ':' is what separates the drive letter from the file path
>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>> full answer, so you might want to take this issue up on
>>> dev@httpd.
>>
>>
>>
>> That looks like it's probably it - there's some discussions in
>> the httpd-dev list that were along these lines. Further to this,
>> a location like
>> <Location /hello/hell::o>
>> ....
>> </Location>
>> does work - what might be happening is Win32 Apache is rejecting,
>> via the 403, anything that looks like a leading drive designation, for
>> security purposes.
>
>
> Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> path? I wonder why Apache can't reject paths with : in the first segment
> only if virtual mapping have failed.
>
>> So it's probably easier to just s!::!-! or s!::!/!, as
>> Stas proposed ...
>
>
> I think that even though <Location Foo/Bar> is more intuitive,
> <Location Foo-Bar> is less error-prone.
>
> I think <Location Foo/Bar> is potentially error-prone, since if one of
> the test package is 'Foo' we will have a location <Location Foo> and
> then we will get merging with <Location Foo/Bar> something that could be
> undesired.
I think that at the end I'm simply going to install a default TransHandler,
semi-transparent to the developer (put it into the autogenerated httpd.conf),
rather than change the URLs.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On 14 Apr 2003, Joe Schaefer wrote:
>>
>>
>>> I'd bet apache is just returning a 403 for security purposes,
>>> since ':' is what separates the drive letter from the file path
>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>> full answer, so you might want to take this issue up on
>>> dev@httpd.
>>
>>
>>
>> That looks like it's probably it - there's some discussions in
>> the httpd-dev list that were along these lines. Further to this,
>> a location like
>> <Location /hello/hell::o>
>> ....
>> </Location>
>> does work - what might be happening is Win32 Apache is rejecting,
>> via the 403, anything that looks like a leading drive designation, for
>> security purposes.
>
>
> Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> path? I wonder why Apache can't reject paths with : in the first segment
> only if virtual mapping have failed.
>
>> So it's probably easier to just s!::!-! or s!::!/!, as
>> Stas proposed ...
>
>
> I think that even though <Location Foo/Bar> is more intuitive,
> <Location Foo-Bar> is less error-prone.
>
> I think <Location Foo/Bar> is potentially error-prone, since if one of
> the test package is 'Foo' we will have a location <Location Foo> and
> then we will get merging with <Location Foo/Bar> something that could be
> undesired.
I think that at the end I'm simply going to install a default TransHandler,
semi-transparent to the developer (put it into the autogenerated httpd.conf),
rather than change the URLs.
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On 14 Apr 2003, Joe Schaefer wrote:
>
>
>>I'd bet apache is just returning a 403 for security purposes,
>>since ':' is what separates the drive letter from the file path
>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>full answer, so you might want to take this issue up on
>>dev@httpd.
>
>
> That looks like it's probably it - there's some discussions in
> the httpd-dev list that were along these lines. Further to this,
> a location like
> <Location /hello/hell::o>
> ....
> </Location>
> does work - what might be happening is Win32 Apache is rejecting,
> via the 403, anything that looks like a leading drive
> designation, for security purposes.
Hmm, is this valid at all on winFU to supply a drive: entry in the URI path? I
wonder why Apache can't reject paths with : in the first segment only if
virtual mapping have failed.
> So it's probably easier to just s!::!-! or s!::!/!, as
> Stas proposed ...
I think that even though <Location Foo/Bar> is more intuitive,
<Location Foo-Bar> is less error-prone.
I think <Location Foo/Bar> is potentially error-prone, since if one of the
test package is 'Foo' we will have a location <Location Foo> and then we will
get merging with <Location Foo/Bar> something that could be undesired.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On 14 Apr 2003, Joe Schaefer wrote:
>
>
>>I'd bet apache is just returning a 403 for security purposes,
>>since ':' is what separates the drive letter from the file path
>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>full answer, so you might want to take this issue up on
>>dev@httpd.
>
>
> That looks like it's probably it - there's some discussions in
> the httpd-dev list that were along these lines. Further to this,
> a location like
> <Location /hello/hell::o>
> ....
> </Location>
> does work - what might be happening is Win32 Apache is rejecting,
> via the 403, anything that looks like a leading drive
> designation, for security purposes.
Hmm, is this valid at all on winFU to supply a drive: entry in the URI path? I
wonder why Apache can't reject paths with : in the first segment only if
virtual mapping have failed.
> So it's probably easier to just s!::!-! or s!::!/!, as
> Stas proposed ...
I think that even though <Location Foo/Bar> is more intuitive,
<Location Foo-Bar> is less error-prone.
I think <Location Foo/Bar> is potentially error-prone, since if one of the
test package is 'Foo' we will have a location <Location Foo> and then we will
get merging with <Location Foo/Bar> something that could be undesired.
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On 14 Apr 2003, Joe Schaefer wrote:
> I'd bet apache is just returning a 403 for security purposes,
> since ':' is what separates the drive letter from the file path
> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> full answer, so you might want to take this issue up on
> dev@httpd.
That looks like it's probably it - there's some discussions in
the httpd-dev list that were along these lines. Further to this,
a location like
<Location /hello/hell::o>
....
</Location>
does work - what might be happening is Win32 Apache is rejecting,
via the 403, anything that looks like a leading drive
designation, for security purposes.
So it's probably easier to just s!::!-! or s!::!/!, as
Stas proposed ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On 14 Apr 2003, Joe Schaefer wrote:
> I'd bet apache is just returning a 403 for security purposes,
> since ':' is what separates the drive letter from the file path
> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> full answer, so you might want to take this issue up on
> dev@httpd.
That looks like it's probably it - there's some discussions in
the httpd-dev list that were along these lines. Further to this,
a location like
<Location /hello/hell::o>
....
</Location>
does work - what might be happening is Win32 Apache is rejecting,
via the 403, anything that looks like a leading drive
designation, for security purposes.
So it's probably easier to just s!::!-! or s!::!/!, as
Stas proposed ...
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Somebody will probably have a reason why ':' is invalid in uri path ;)
I'd bet apache is just returning a 403 for security purposes, since ':'
is what separates the drive letter from the file path on Windows.
Superman^H^H^H^H^H^HWilliam Rowe probably knows the full answer, so you
might want to take this issue up on dev@httpd.
> 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.
+1 to eliminating ':' from the test locations; I don't have a
preference on '-' vs '/' though.
--
Joe Schaefer
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Somebody will probably have a reason why ':' is invalid in uri path ;)
I'd bet apache is just returning a 403 for security purposes, since ':'
is what separates the drive letter from the file path on Windows.
Superman^H^H^H^H^H^HWilliam Rowe probably knows the full answer, so you
might want to take this issue up on dev@httpd.
> 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.
+1 to eliminating ':' from the test locations; I don't have a
preference on '-' vs '/' though.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
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
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
> > 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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
> > 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.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
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?
> 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).
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
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?
> 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).
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
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.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
>>This looks like a bug in apreq then.
>
> ^^^^^
>
> ITYM apache-1.3.X on Windows?
Yes.
> In any case, it's
> certainly not apreq that's producing a 403 status.
Right, httpd-test/perl-framework has no <Location foo::bar> entries, so it's
not tested. So it's a bug in apache-1.3 then?
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?
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
>>This looks like a bug in apreq then.
>
> ^^^^^
>
> ITYM apache-1.3.X on Windows?
Yes.
> In any case, it's
> certainly not apreq that's producing a 403 status.
Right, httpd-test/perl-framework has no <Location foo::bar> entries, so it's
not tested. So it's a bug in apache-1.3 then?
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?
__________________________________________________________________
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
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> This looks like a bug in apreq then.
^^^^^
ITYM apache-1.3.X on Windows? In any case, it's
certainly not apreq that's producing a 403 status.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> This looks like a bug in apreq then.
^^^^^
ITYM apache-1.3.X on Windows? In any case, it's
certainly not apreq that's producing a 403 status.
--
Joe Schaefer
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
[CC'ing apreq-dev]
Randy Kobes wrote:
> In trying to run the tests under Win32 in httpd-apreq (which are
> being converted over to use the Apache-Test framework), I ran
> into something. At present, under certain conditions some
> <Location > directives will be automatically generated like
> <Location /TestApReq::inherit>
> SetHandler perl-script
> PerlHandler TestApReq::inherit
> </Location>
> Such tests in httpd-apreq generate 403 errors, I think because on
> Win32 colons are invalid in filenames - manually changing the
> location to, eg, TestApReq-inherit, and adjusting the request in
> the corresponding .t file accordingly, gets rid of this error. I
> checked this also happens in my "real" Apache configuration (both
> 1 and 2) - simply changing a working <Location> directive (not
> corresponding to any physical file) to having a colon in the name
> generates an error.
>
> This problem seems subtle ... For one thing, the mod_perl 2 tests
> use this <Location> convention with colons, and they work on
> Win32. So this can be made to work, somehow. Also, I would have
> thought <Location> directives would be checked even before
> filenames - for example, a <Location /hello> takes precedence
> over a physical file @@DocumentRoot@@/hello. But perhaps, for the
> purposes of Apache-Test, these subtelties may be academic - since
> the httpd-apreq tests seem OK, and might be something that a
> typical user might generate, it might save some problems in the
> future to change the <Location> directives to use, eg, '-' rather
> than '::' in the names?
This looks like a bug in apreq then.
':' is a valid character in the path component
http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html#3.3
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
[CC'ing apreq-dev]
Randy Kobes wrote:
> In trying to run the tests under Win32 in httpd-apreq (which are
> being converted over to use the Apache-Test framework), I ran
> into something. At present, under certain conditions some
> <Location > directives will be automatically generated like
> <Location /TestApReq::inherit>
> SetHandler perl-script
> PerlHandler TestApReq::inherit
> </Location>
> Such tests in httpd-apreq generate 403 errors, I think because on
> Win32 colons are invalid in filenames - manually changing the
> location to, eg, TestApReq-inherit, and adjusting the request in
> the corresponding .t file accordingly, gets rid of this error. I
> checked this also happens in my "real" Apache configuration (both
> 1 and 2) - simply changing a working <Location> directive (not
> corresponding to any physical file) to having a colon in the name
> generates an error.
>
> This problem seems subtle ... For one thing, the mod_perl 2 tests
> use this <Location> convention with colons, and they work on
> Win32. So this can be made to work, somehow. Also, I would have
> thought <Location> directives would be checked even before
> filenames - for example, a <Location /hello> takes precedence
> over a physical file @@DocumentRoot@@/hello. But perhaps, for the
> purposes of Apache-Test, these subtelties may be academic - since
> the httpd-apreq tests seem OK, and might be something that a
> typical user might generate, it might save some problems in the
> future to change the <Location> directives to use, eg, '-' rather
> than '::' in the names?
This looks like a bug in apreq then.
':' is a valid character in the path component
http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html#3.3
__________________________________________________________________
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