On 14 September 2016 at 09:41, Greg Wilkins <gregw_at_webtide.com> wrote:
> There are two aspects of the spec as currently written:
>
> 1. The context path returned is encoded (or more precisely non
> decoded).
> 2. It is implied, but not explicit, that the encoding returned is that
> provided by the client, which may be non-normalized, variously encoded and
> containing path parameters.
>
> I see no good reason for 1., but since the spec is written that way and
> 99.9999% of contexts don't need encoding, I don't think it is a big problem
> to support. So we can return it encoded.
>
> It is 2. that is a HUGE -1 for us, as it is both difficult and dangerous.
> Hearing tomcats experience just confirms that we really should not do this
> in jetty. I think the spec is ambiguous enough to give us some wiggle
> room to improve this method with minimal breakage. How about:
>
> The context path returned is encoded with the containers preferred
> encoding for the context portion of the request URI
>
> This keeps the current specified encoded return for the method, but it
> gives the containers version rather than the unconstrained users provided
> version. This still allows for a context to have multiple context paths,
> and such a container will just have to have multiple preferred encodings
> (or re-encode on the fly).
>
> For the vast majority of webapps, they will see no difference as the
> context path will not change when encoded. There is no security hole
> opened up (or the existing one closed) as unconstrained user bytes are no
> longer provided to the application. The implementation is not difficult.
>
> I can't think of a reasonable webapp that will break with this change -
> what webapp would depending on seeing different encodings of the same
> context path provided by the client?
>
Note that in our next jetty dot release: 9.4.0, we have decided to go with
this interpretation. The contextPath will be returned encoded, but not
the clients encoding.
We see this as the safest approach as it does not expose applications to
arbitrary client supplied strings, but it respects the spec as written in
as much as the contextPath will be encoded for those applications that a)
expect it to be; b) have a contextpath that is actually different when
encoded.
cheers
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com