The second variation looks like what you might get if the request-body is parsed as XML when returned from xdmp:get-request-body(). As you've found out, in that case calling xdmp:unquote is not a good idea, because it treats the input as a string. So the result is the unquote of the fn:string(...) value of the XML node.
I can't explain why one text/plain variant produces text and another seems to produce XML. I'd expect that behavior to follow the mime-types configuration (at http://localhost:8001/mimetypes-admin.xqy if your server is local). But to me the question is: why use unquote at all? Wouldn't it be better to require the request to specify an XML content-type in the first place? With the default mimetypes, I think 'text/xml' or 'application/xml' should work. That way xdmp:get-request-body knows that the body is XML, and parses it as such. Otherwise your service is in the position of assuming that a text/plain request is really an XML request. That feels a bit odd.... -- Mike On 19 Oct 2012, at 22:33 , "Harry B." <[email protected]> wrote: > I've got a restful service that behaves differently with different > clients/sources. Let me illustrate- > > The POST request is expecting an xml payload such as this: > > <payload> > <searchRequest> > <searchTerm>Foo</searchTerm> > <constraint>bar</constraint> > ... > </searchRequest> > </payload> > > To get the request, I use xdmp:unquote(xdmp:get-request-body())/node() > > This works fine from a Firefox plugin rest client I use. I am able to > traverse the xml and all is well. However, when I use SoapUI, there's a > problem. Performing the unquote results in all the element names being > stripped out so instead of- > > <searchRequest> > <searchTerm>Foo</searchTerm> > <constraint>bar</constraint> > ... > </searchRequest> > > I see something like- > > | > Foo > bar > ... > | > > (pipes show beginning and end) > > If I don't use unquote on this request from SoapUI, the code works. > > In the end, I found that the difference is in the content-type header value. > The requests that work properly with the xdmp:unquote call have content-type > of "text/plain; charset=UTF-8" but those that don't are "text/plain". I have > a work-around to check this value and set the payload variable accordingly, > but I'd like to understand what is going on. What should I be doing > differently to prevent this sort of issue? > > Thanks, > Harry > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
