On 08/09/2016 08:20, Greg Wilkins wrote:
> Stuart,
>
> I'm hoping everybody else missed it too. The TCK certainly didn't test
> for it!
Tomcat did miss it originally but we caught it about about 2.5 years ago:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56501
The encoding / normalization problems were caught about a year later:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57215
Implementation was "interesting"[1] since "not decoded" also means "not
normalized". Throw in path parameters as well and you have all sorts of fun.
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 have seen the method used to build encoded URIs. Tomcat does this in
its own examples and the Manager application.
I think either option (fix the other containers or change the spec) is
going to lead to breakage somewhere. Given the minimal reaction there
was to Tomcat fixing this, I suspect that breakage will be small either
way. I'm very much on the fence as to which way to go on this.
> Delaying the decoding choice doesn't help much as you have to decode the
> whole url first just to work out which context it matches. Remember
> their are many encodings of a context path so you can't match on encoded
> uri.
+1
Mark
[1]
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java?view=annotate#l1938
>
> Cheers
>
>
> On 8 Sep 2016 17:01, "Stuart Douglas" <sdouglas_at_redhat.com
> <mailto:sdouglas_at_redhat.com>> wrote:
>
> 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
> <mailto: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_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com
>
>