-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for obtaining path parameter information from HttpServletRequest #67
Comments
@glassfishrobot Commented |
@glassfishrobot Commented
|
@glassfishrobot Commented |
@glassfishrobot Commented
This probably reflects the fact that a few different styles of path parameters have evolved over time in the absence of a very precise definition. In addition to the above examples, here is one other example from the StackExchange API where a path segment contains a ";" separated list of ids (the ";" in this case is merely a separator): http://api.stackoverflow.com/1.1/usage/methods/comments-by-ids |
@glassfishrobot Commented |
|
URI paths can contain parameters, independent of the query string. Parameters belong to the path segment within which they appear and to the URI as a whole. Parameters are separated from the segment and from each other with a semicolon (;), and parameter values are separated from each other with a comma (,). For example, consider the following URL:
http://www.example.org/foo;x=1;y=2/bar;a=3,4;y=5
In this example, x is 1 and y is 2 or the /foo segment, while a is [3, 4] and y is 5 for the /bar segment. For the entire URL, a appears once and has 2 values, x appears once and has 1 value, and y appears twice and has 1 value and 1 value.
The servlet spec already recognizes path parameters, though it does not actually provide an interface for extracting them. As an example of this, if application /foo is deployed at example.org and it has a Servlet mapped to /bar, the aforementioned URL will match that context and servlet. A call to HttpServletRequest#getContextPath() will return /foo, not /foo;x=1;y=2, and a call to HttpServletRequest#getServletPath() will return /bar, not /bar;a=3,4;y=5.
This suggestion is to add two methods to HttpServletRequest:
A call to either getPathParameters or getPathSegments results in the processing and caching of all path parameters. This is independent of the processing and caching of request parameters (getParameter, getParameterNames, etc.). The processing of path parameters should not trigger the processing of request parameters, and vice versa. If easier/more efficient, the container may process path parameters when it decodes the URI (note that parameter processing should be performed against the URI before decoding, but parameter names and values should be decoded).
(Importantly, if I call getPathParameters or getPathSegments within a filter, it should not block while POST parameters or multipart data (unrelated) are processed.)
The new javax.servlet.http.PathSegment interface is modeled off of the javax.ws.rs.core.PathSegment interface, which exists for the same purpose:
There is currently a workaround to accomplishing this, though it has its disadvantages. Parameters could simply be processed as-needed by the application using its own or third-party code. Or a filter could be written to process parameters and add them to the request as a request attribute. The key problem with both of these approaches is that the container knows what character encoding was used for the URI, but the application does not. It would be more accurate and reliable for the container to perform the parameter processing.
For the most information, I have included parts a sample filter below that I created for use in my application. Some of the code (namely the POJOs) is inferred.
Estimate 30 minutes to add the relevant methods/interfaces and 2.5 hours to update the spec doc.
Environment
n/a
The text was updated successfully, but these errors were encountered: