Hi Ivan, hi Gerrit,
Thanks for your assessments.
Most design decisions in RESTXQ have been taken from Java’s JAX-RS API [1]. The semantics for accessing paths is a bit more complex, though: JAX-RS provides two annotations @Path and @PathParam to access the full path and segments of the path, and the segments are automatically decoded. Automatic decoding can be disabled via an optional @Encoded annotation.
In RESTXQ, we only have a single %rest:path annotations, which contains both the full path as well as variables for path segments.
Requests with wrongly encoded URLs, such as http://localhost:8984/a%2, are already rejected by Jetty (and, I guess, any other web servers). They are rejected before any RESTXQ code can intervene. If a URLs is correctly encoded, the Java servlet function getPathInfo() is used to obtain the path. I noticed there is an alternative function getRequestURI() that could be used to access the original URL.
Maybe the introduction of a %rest:encoded annotation could be discussed in the EXQuery/RESTXQ repository [2]?
Best, Christian
[1] https://download.oracle.com/otndocs/jcp/jaxrs-2_0-fr-eval-spec/index.html [2] https://github.com/exquery/exquery/issues
On Fri, Jan 24, 2020 at 2:38 PM Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de wrote:
On 24.01.2020 14:36, Imsieke, Gerrit, le-tex wrote:
So I agree, BaseX should not interpret escaped slashes as if they were regular slashes, thereby disallowing them as part of RESTXQ path pa
…rameters.