jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: encoded context path!?!?

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Thu, 8 Sep 2016 17:01:08 +1000

Looks like Undertow also has the same issue. If it turns out that
everyone has implemented it the same (wrong) way maybe we should look
at changing the spec instead.

Personally I don't think this makes much sense that this is not
decoded while getServletPath and getPathInfo are not. The only
possible reason I can think of is that maybe it is to allow you to
select the URL encoding on a per application basis (basically you
could hold off on URL decoding till the request has been mapped to an
application), but I think that is a fairly weak reason.

Stuart

On Thu, Sep 8, 2016 at 3:24 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
> All,
>
> I've just discovered that jetty is not correctly implementing
> HttpServletRequest.getContextPath(), which you would think would be a pretty
> fundamental thing!
>
> According to the javadoc, the container does not decode the string, so it
> would not return "/context path", rather it should return "/content%20path",
> or even "/c%6Fntent%20path" if that is what the client sent!
>
> Luckily such encoded context paths are very rare!
>
> However, we would like to be compliant, so we are fixing this, but I'd just
> like to check regarding ServletContext.getContextPath(), as its javadoc does
> not mention if it is encoded or not. I would assume that it is?
>
> Eitherway, we should probably fix the javadoc for that.
>
> regards
>
> PS. Does anybody know the reason getContextPath is encoded while
> getServletPath and getPathInfo are not? I had always thought only
> getRequestURI was encoded?
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com