bug #42120: Apache improperly handling Path Component parameters?

[Andy Wang <aw...@ptc.com>]

I just submitted bug 42120.  It appears that Apache is improperly (at 
least I think it's improper) matching Location blocks when doing 
authentication if a path component parameter is passed on.

Specifically, something like this
<Location /webapp/servlet/SomeServlet>
  {Auth stuff}
</Location>

In this scenario, if I hit http://server/webapp/servlet/SomeServlet I'll 
be properly challenged.  However, if I generate a servlet URL with the 
jsession ID as a parameter rather than a cookie, the URL will look 
something like 
http://server/webapp/servlet/SomeServlet;jsessionid=[sessionid] and 
Apache fails to properly challenge for authentication.

There are a number of potential workarounds (LocationMatch, or Multiple 
Location blocks to deal with the ;* pattern) but it does seem like this 
is a bug unless someone can clarify RFC 2396 section 3.3 for me and 
explain why it isn't.

Agree or disagree?

Thanks,
Andy

Re: bug #42120: Apache improperly handling Path Component parameters?

[Jess Holle <je...@ptc.com>]

Nick Kew wrote:
> On Fri, 13 Apr 2007 16:30:06 -0500
> Andy Wang <aw...@ptc.com> wrote:
>   
>> There are a number of potential workarounds (LocationMatch, or
>> Multiple Location blocks to deal with the ;* pattern) but it does
>> seem like this is a bug unless someone can clarify RFC 2396 section
>> 3.3 for me and explain why it isn't.
>>     
> Your reading of the RFC is correct but irrelevant. The semantics of 
> <Location> are (like <Directory>) based on path components.
>   
It's clear they are today, but is that really proper?

Java servlet engines have an encodeURL() API that is the standard means 
of cookie-less session passing and uses exactly this URL syntax.

Thus anyone using Location in conjunction with Java servlet engines may 
be getting unexpected results.  For instance, using Location /x/y/z to 
establish authentication via Apache will not establish authentication on 
/x/y/z;jsessionid=xxx -- yet the servlet engine will treat the two the 
same (except that the latter denotes a particular session).  This is 
thus a security hole for the unaware (if they were using authentication 
to prevent access to those resources, not just to establish identity for 
use of them).

We can certainly change add more Location blocks or use LocationMatch to 
handle /x/y/z;*, but this seems to be a clear disconnect between 
Apache's Location notion and that of both the RFC and Java servlet engines.

I realize that this is an old issue that has been left "as is" for 
years.  We're running into it only now because we normally only allow 
cookie-based session passing but suddenly have cause to support this 
form as well in some corner cases.  While we can work around the issue 
it would seem Location should simply be fixed.

--
Jess Holle

Re: bug #42120: Apache improperly handling Path Component parameters?

[Andy Wang <aw...@ptc.com>]

Nick Kew wrote:
> On Fri, 13 Apr 2007 16:30:06 -0500
> Andy Wang <aw...@ptc.com> wrote:
>
>   
>> There are a number of potential workarounds (LocationMatch, or
>> Multiple Location blocks to deal with the ;* pattern) but it does
>> seem like this is a bug unless someone can clarify RFC 2396 section
>> 3.3 for me and explain why it isn't.
>>     
>
> Your reading of the RFC is correct but irrelevant. The semantics of 
> <Location> are (like <Directory>) based on path components.
>
>
>   
Doesn't that more or less support my interpretation?  If the semantics 
of <Location> are based on path components, and the RFC 2396 section 3.3 
defines the grammar for Path Component, and according to that grammar 
param's are not significant when parsing them, shouldn't apache also not 
include parameter's when attempting to match a URI's path component to a 
<Location> block?

Andy

Re: bug #42120: Apache improperly handling Path Component parameters?

[Nick Kew <ni...@webthing.com>]

On Fri, 13 Apr 2007 16:30:06 -0500
Andy Wang <aw...@ptc.com> wrote:

> There are a number of potential workarounds (LocationMatch, or
> Multiple Location blocks to deal with the ;* pattern) but it does
> seem like this is a bug unless someone can clarify RFC 2396 section
> 3.3 for me and explain why it isn't.

Your reading of the RFC is correct but irrelevant. The semantics of 
<Location> are (like <Directory>) based on path components.


-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/