Hello, we recently observed an unexpected behaviour in how MarkLogic treats the keys in the query part of a submitted URL (note the case of the two query param keys):
http://localhost:9999/app/test.xqy?param=yes&Param=no let $q1 := xdmp:get-request-field('param') let $q2 := xdmp:get-request-field('Param') return "q1: " || $q1 || " -- q2: " || $q2 one should reasonably expect to see the following result: q1: yes -- q2: no However, the actual result is an error because "arg1 is not of type xs:anyAtomicType?" XDMP-ARGTYPE: (err:XPTY0004) "q1: " || $q1 || " -- q2: " || $q2 -- arg1 is not of type xs:anyAtomicType?in /app/test.xqy, at 7:11 [1.0-ml] $q1 = ("yes", "no") $q2 = ("yes", "no") xdmp:get-request-field-names() correctly returns both 'param' and 'Param'. For some reason, MarkLogic normalises (presumably lowercases) the keys of the query string when looking up a query parameter value which seems to be counter to what is described in section 6.2.2.1 Case normalisation of RFC 3986 [1]: When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI <HTTP://www.EXAMPLE.com/> is equivalent to < http://www.example.com/>. *The other generic syntax components are assumed to be case-sensitive* unless specifically defined otherwise by the scheme (see Section 6.2.3). Are we interpreting the RFC wrongly? Yes, I've tested this on 8.0-6.3. cheers, Jakob. PS: Thanks to my colleague Romuald for mentioning this over beer! ;-) [1] https://tools.ietf.org/html/rfc3986#section-6.2.2.1
_______________________________________________ General mailing list General@developer.marklogic.com Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
