tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
Date Wed, 02 Mar 2005 22:33:22 GMT
Jan Luehe wrote:
> Remy,
> Remy Maucherat wrote:
>>Jan Luehe wrote:
>>>But SRV.9.10 ("Welcome Files") already has this:
>>> The container may send the request to the welcome resource with
>>> a forward, a redirect, or a container specific mechanism
>>> **that is indistinguishable from a direct request**.
>>>The latter to me implies that any sec constraints must be applied
>>>to the mapped welcome page (if any).
>>The plot thickens.
> What do you mean by that? ;-)
> Do you agree the spec is pretty clear about the fact that
> any sec constraints must be applied to welcome page?

It means that the statement would seem to be conflicting with other 
things, but still seems relevant to the topic. So it makes the problem 
more complex.

>>Right. However, when I made that commit, the current mapper behavior may 
>>not have been in place already, or maybe it's simply that I thought the 
>>two would be equivalent (I was busy optimizing at the time). I don't 
>>quite remember ;)
> I think you did the right thing without realizing it. :)
> The change I committed earlier today is just consistent with
> what you had done.

I was out to kiil the substring thing.

> I'm still nervous about request.getDecodedRequestURI() returning
> the original URI even after the request has been mapped to a welcome
> page. This violates spec requirement that any container specific
> mechanism for mapping request to welcome page must be
> "indistinguishable from a direct request".

Changing this is very risky, as it will have uses elsewhere. If using 
Eclipse, you should use the call hierarchy (since it's an internal 
method which is never used through reflection).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message