Nick Kew wrote:
On Fri, 13 Apr 2007 16:30:06 -0500
Andy Wang <[EMAIL PROTECTED]> 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
