Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[servlet-dev] Path Parameters


All,

the servlet spec in section 3.1 says: 
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

--

Back to the top