Hi,
There is no distinction between a query param and a path param in the requestContext.params() method or the requestContext.getParam('name') call.
If there is no guarantee that the param comes from the path, then a request could be constructed to overwrite the path param with a query param.
e.g. http://some.host.com/:name can be called with
http://some.host.com/fred?name=george causing a possible security issue
@plenderyou path params are a not official "parameters" in the sense that they are not part of the HTTP query string, so in vert.x-web as in many other frameworks they are just masked as being part of the query string.
Once you use both query string and path params with the same name you will end up with a unordered list with all results for example in your case: [fred, george].
If you want to be sure there's only 1 value then you should use rc.request.params.getAll('name') and work with the list. If you just use get('name') then you only get the last added value which is the path one (query processing happens before path when filling the variable).
Ok, I understand.
When writing REST services path params are often used, I guess I'll just have to filter out the query params in code to ensure no-one is trying to circumvent the call by overriding the parameter.
I do think this is a security issue though and since vertx-web supports the concept of path params it should provide an easy way to distinguish between the 2 types.
Agreed, a way to make the distinction would be welcomed.
I'm considering this a bug. Please make this behavior configurable and have a second map with the path parameters.
For queries where callers can use any valid parameter name, this leads to unexpected problems.
@beders it is not a bug since it was never documented or said that is was supposed to behave like that. It is in fact a new feature that should be implemented. Of course if this is too critical for you you're always welcome to submit a PR since the vert.x team is very busy with many features and this one has a low priority for now.
I don't consider this a bug, either a choice or a missing feature, but I do agree it'd be a nice improvement. Many frameworks provide this distinction (think of JAX-RS @QueryParam vs. @PathParam or Spring MVC @PathVariable vs. @RequestParam).
Security aside, I prefer this approach for code readability. Sometimes the code handling the parameter is not close to the route declaration, and thus getParam can be misleading for the reader (if the route is declared 3 lines above, no problem obviously). So 馃憤 for me.
Fixed by #363
Most helpful comment
I don't consider this a bug, either a choice or a missing feature, but I do agree it'd be a nice improvement. Many frameworks provide this distinction (think of JAX-RS
@QueryParamvs.@PathParamor Spring MVC@PathVariablevs.@RequestParam).Security aside, I prefer this approach for code readability. Sometimes the code handling the parameter is not close to the route declaration, and thus
getParamcan be misleading for the reader (if the route is declared 3 lines above, no problem obviously). So 馃憤 for me.