Re: [servlet-dev] Path Parameters

[Mark Thomas <markt@xxxxxxxxxx>]

On 12/02/2021 17:11, Greg Wilkins wrote:
> So this gives us two problems.   Firstly I now cannot find any current
> specification of HTTP URL path parameters and how they should be
> parsed.   So I think the servlet spec could be relying on the
> grandfathered definition from RFC2396.  IS this true?  Does anybody know
> of a current specification for them?

I'm not aware of anything better than the references you have provided.

> Secondly, because the path segment normalization is defined in RFC 3986
> in terms of complete segments that are exactly "." or "..", this results
> in a URI like 
> 
>     /context/path/..;/other/info 
> 
> being canonical and it is incorrect to resolve it to 
> 
>     /context/other/info 
> 
> The problem here is that once we strip the parameters as required by the
> servlet spec, we get the ambiguous path results based on the string
> 
>     /context/path/../other/info 
> 
> 
> In Jetty, we already handle ambiguous URIs like/foo/%2e%2e/bar with a
> 400 and intend to do the same with /foo/..;/bar and /foo/%2f/bar.  How
> do the other container handle such URIs?

In Tomcat we process URIs with the following sequence:
- separate the query string (if any)
- parse the path parameters (we are only interested in jsessionid or
  equivalent) and remove them from the URI
- %nn decode the URI
- normalize the URI
- map the URI to virtual host, web app, filters, security constraints,
  servlet etc.

This approach evolved over time. It derived from the:

"Path parameters that are part of a GET request (as defined by HTTP 1.1)
are not exposed by these APIs. They must be parsed from the String
values returned by the getRequestURI method or the getPathInfo method."

text in the Servlet spec.

The argument for this approach goes something like:

If a servlet is mapped to "/foo/bar" it is possible that foo may have an
optional (or required) path parameter.

The servlet spec provides no way to map a servlet based on the value or
range of values for that path parameter.

Given all of the above when receiving a request of the form
"/foo;v=1/bar" there were several ways to handle it:

1. Reject it outright. There does not seem to be any basis for this
approach. The quoted text above strongly implies that requests with path
parameters are permitted by the Servlet spec.

2, Map it as-is. There is no way defined to specify more than one value
for a path parameter in a servlet mapping. Mapping each individual value
(or combination values) is very likely to be impractical. Any unmatched
request will be directed to the default servlet which is unlikely to be
the desired outcome. The combination of the impracticality and undesired
outcome makes this approach unrealistic.

3. Strip the path parameters and then map it. While not explicitly
stated as the intended behaviour in the spec, this is a practical
solution that works for the few users that need path parameters and
seems most consistent with the quoted servlet spec text above.

The downside with approach 3 is that when used behind a reverse proxy,
and depending on how the reverse proxy does the request mapping, it may
be possible to bypass path based security constraints defined in the
reverse proxy. If the reverse proxy is using path matching as a security
control, URIs containing "/..;/" may bypass that control. The Tomcat
provided proxy modules (mod_jk, ISAPI redirector) map requests using the
same algorithm as Tomcat to avoid this potential issue.

Mark