On 8 September 2016 at 20:53, Mark Thomas <markt_at_apache.org> wrote:
> I'd dearly like to be able to ditch that implementation and replace it
> with the one liner that would return the decoded path.
>
I really think we should give Mark the simple life he yearns for :)
Note that with the spec as it stands, there is no simple call to access to
the decoded normalized deparameterized context path. If the spec is to
remain as is, then we probably need to provide a getContextPathDecoded()
method and encourage its use as a matter of some urgency.
I would hazard a guess that most URIs with encoded denormalized
parametrized context paths are created by attackers trying to trick poorly
coded applications that are using context path and never thought that it
could look like /harmless/../ev%69l;nothing=to;see=here
Considering that this has not been a problem for the vast majority of
webapps and that it was only recently reported on tomcat, does indicate
that the impact of reverting to decoded would be small. Changing
containers to decoded has a potential much larger impact even if it
appeared small when tomcat changed. It may have a small functional impact,
but I'm not so sure it's security impact will also be small. It is a
big change for jetty/undertow/etc. to suddenly start exposing all their
deployed base to none normalized client supplied data!
So I'm obviously in favour of making this an errata on 3.1 and fixing the
4.0 spec!
cheers
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com