Mark Thomas wrote:
>> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404
>> from Tomcat becasue it will pass the original uri, not the one Httpd
>> already unfolded)
> This is correct and provides consistent behaviour for direct to Tomcat
> access and access via mod_jk.
>
It is not correct behavior, because we are stripping down the
entire Httpd filter chain.
>> mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount
>> /appB/*
> This double decoding prevents legitimate access to perfectly valid
> files that contain the % character in their name.
>
How many times I have to repeat. The uri is *not* decoded twice.
It is decoded *only once* by the Apache Httpd.
And please test the patch before making comments like that,
because it will not allow nor disallow anything except
back mappings (the one that were not specified by JkMount).
Again, no. It doesn't touch the original uri.
But this is wrong. The url should only be decoded once in the
processing chain.
Did I mention that uri is *not* decoded twice?
I can see how this would provide a safe alternative for users that the
1.2.23 fix caused problems for but I do not believe it should be the
default.
I would suggest:
- keep the 1.2.23 behaviour (+ForwardURICompatUnparsed) as the default
- modify the ForwardURICompat option to include this additional check
mod_jk is present for years, and now suddenly changing the
default behavior makes users surprised with mod_rewrite not
working any more. This change was accepted and made only as
a temporary solution to CVE 2007-0774, and as such must be resolved,
rather then hidden inside.
This approach:
- maintains the security of 1.2.23
- ensures the url is decoded only once by default
- provides a safe option for users that want/need/expect double decoding
Did I mention that uri is *not* decoded twice?
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
