[Bug 57559] New: Decoded Request URI used for Asynchronous dispatch

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57559

            Bug ID: 57559
           Summary: Decoded Request URI used for Asynchronous dispatch
           Product: Tomcat 7
           Version: 7.0.53
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: cg.throwaway@mailinator.com

Overview:

In a scenario where an original request contains part of the URI
percent-encoded (e.g. /context/foo/%24/bar), when the request is put into
asynchronous mode using ServletRequest.startAsync() and then dispatched using
the no-argument AsyncContext.dispatch() method, the dispatch is incorrectly
made to a percent-decoded URI (e.g. /context/foo/$/bar), not the original
request URI.

Steps to Reproduce:

Consider the following servlet:
https://gist.github.com/anonymous/957122b45ae656a5e8f1
It puts a request into asynchronous mode using ServletRequest.startAsync() and
immediately dispatches it using the no-argument AsyncContext.dispatch() method.
When the asynchronous dispatch takes place, the request URI is written to the
response.

1) Compile and deploy the servlet to http://localhost:8080/context
2) Visit http://localhost:8080/context/foo/%24/bar (or any similar
percent-encoded URI) in your browser

Actual Results:

The printed-out request URI is /context/foo/$/bar (i.e. the request has been
dispatched to /context/foo/$/bar, a percent-decoded version of the original
URI)

Expected Results:

The printed-out request URI is /context/foo/%24/bar (i.e. the request should be
dispatched to /context/foo/%24/bar, the original URI)

Additional Information:

The Java Servlet 3.0 Specification says: "The dispatch method takes no
argument. It uses the original URI as the path. If the AsyncContext was
initialized via the startAsync(ServletRequest, ServletResponse) and the request
passed is an instance of HttpServletRequest, then the dispatch is to the URI
returned by HttpServletRequest.getRequestURI(). Otherwise the dispatch is to
the URI of the request when it was last dispatched by the container."

It seems clear that the dispatch should be to the original request URI as
obtained from HttpServletRequest.getRequestURI(), and the Javadoc of
HttpServletRequest.getRequestURI() states that "The web container does not
decode this String." Therefore, it seems the asynchronous dispatch should not
be made to a percent-decoded version of the original URI, but to the original
URI as-is.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 57559] Decoded Request URI used for Asynchronous dispatch

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57559

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 57559] Decoded Request URI used for Asynchronous dispatch

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57559

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The specification text you quoted skips over a few things. The main one is how
tricky it is to split an undecoded URI into contextPath, servletPath and
pathInfo. See the getContextPath() implementation in [1] for an idea of just
how messy this could get. I have no desire to see that sort of code in
something that is meant to be a convenience method.

Elsewhere in the Servlet spec (including for async) dispatches are handled in
terms of decoded paths relative to a context root. The convenience dispatch()
methods needs to be handled the same way to avoid a whole pile of unnecessary
complexity.

If you need the original request URI it is available via the usual request
attribute.

I'll raise this with the Servlet EG to see if the wording of this can be
changed/improved but - as far as Tomcat is concerned - this is a WONTFIX. Note
if the EG opt for the behavior you are asking for I'll re-open this issue.

I've added a test case that confirms the observed behavior.


[1]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?view=annotate

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 57559] Decoded Request URI used for Asynchronous dispatch

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57559

--- Comment #2 from Konstantin Kolinko <kn...@gmail.com> ---
Previous discussion of this issue, ~8 months ago (June 2014):

"Decoded URL set on asynchronous request"
http://tomcat.markmail.org/thread/e33tqu7ayp2fguh4

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org