Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
Bill/Remy,
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).
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
