Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Because it is on the Tomcat side and it ends up
as /otherapp/danger.
No it is not. If you send
/myapp/%252e%252e/otherapp/danger
to Tomcat, it will map the URL into the /myapp context (which is correct).
Now, your suggestion would send an faulty uri for
something that shouldn't be passed by the mod_jk at
the first place, because *we know* how the uri will
be decoded on Tomcat.
Unless we change the AJP connector, there are only three possibilities:
- either we iterate over URL decoding unless no more '%' signs are in it
- or we deny all URLs with '%25' in them
- or we reencode the URL
As I understand you, the first two are more what you are about. But this
will not allow any requests to be processed, which have a percent
character as part of their ressource description. But those URLs are valid!
Once again: I think that reencoding and afterwards decoding by Tomcat is
the identity operation. So we are in the very god situation, that all
mod_jk/httpd logic has been done against the same URL, that will be used
by Tomcat.
I tried to provide some evidence, why a *decoded* URL of the form
/myapp/%2e%2e/otherapp/danger
is valid, is unequal to /otherapp/danger and belongs to the /myapp
context. Also I showed, why double decoding usually is assumed to be bad
practise. Assume there s some content scanning in front of Apache and we
double decode, then the same problem will be between the component in
front and us. We will end up by simply denying everything with '%25' in
it and I find that much more inadequate then reencoding the URL.
Why do you think it is a "faulty uri" and we shouldn't pass it along?
Simply reencode and erything is fine.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
