Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

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

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

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.

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

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

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

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

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

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