Re: [servlet-dev] Path Parameters

[Stuart Douglas <sdouglas@xxxxxxxxxx>]

On Sat, 13 Feb 2021 at 04:12, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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?

No idea. In my experience users actually wanting path parms in the middle of the URL is pretty rare. I think they were a mistake, they add a lot of complexity for very little gain.

 

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?

I think sending a 400 is perfectly reasonable.

Stuart

 

regards

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev