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.
I think when those words were written URIs were defined by
RFC2396 which well defined path parameters in section 3.3:
path = [ abs_path | opaque_part ]
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
However, that RFC has since been obsoleted by
RFC3986 which now no longer has a normative definition for path parameters and instead just says:
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
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?
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?
regards
--