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
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.
While moving the URI parameter to the query string seems like an
acceptable workaround, I, too, suggest that if *reserved* URI characters
such as '/' appear percent-encoded, they should not be converted to
their decoded character prior to analyzing the URI, in line with Sect.
2.2 of RFC 3986 [1
Hi Christian,
thanks for the quick reply. It definitely helps, but it still keeps
this behaviour in the "weird" domain.
I do not see a reason to be decoding the URI before it gets to match a
route. What is the reason for this?
What you propose works, but if I have a route like
"/search/{$query=.+
Hi Ivan,
A more common approach is to supply search terms as query parameters
(URL?query=...); in that case, your path won’t have new segments. If
you prefer paths, you can use a regular expression in your RESTXQ path
pattern [1]:
"search/{$query=.+}"
In both cases, encodeURIComponent should b
5 matches
Mail list logo