httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: bug #42120: Apache improperly handling Path Component parameters?
Date Sat, 14 Apr 2007 13:22:22 GMT
Nick Kew wrote:
> On Fri, 13 Apr 2007 16:30:06 -0500
> Andy Wang <awang@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

Mime
View raw message