Turn off additional response headers from v1/eval API in MarkLogic

Question

In MarkLlogic, when invoking the v1/eval endpoint, the response is peppered with "extra headers" that are not suppressed by using the --silent flag.

Example: curl --silent -u user:pass --digest -X POST --data xquery@test.xqy http://localhost:8000/v1/eval

Where test.xqy contains

(1, 2, 3)

Results in something like:

--e17f2058da4654f7
Content-Type: text/plain
X-Primitive: integer

1
--e17f2058da4654f7
Content-Type: text/plain
X-Primitive: integer

2
--e17f2058da4654f7
Content-Type: text/plain
X-Primitive: integer

3
--e17f2058da4654f7--

The desired result is:

1
2
3

This is quite an effort to parse and clean up, especially in a shell script.

Is there any way to clean up the response by passing additional options to either curl or to the v1/eval endpoint?

Answer 1

[Edited after further discussion]

MarkLogic:

The eval endpoint only returns multipart/mixed. Give it a sequence of N and you get N boundaries. There is no way to change this behavior for the endpoint in question. Alternative would be to create your own REST extension or a main module and use v1/invoke

cURL:

A data transport tool that -by design - does not know or care about the details the content of the data transferred. It has no idea of what a multi-part message is.

So, between the two tools, there is no actual solution on it's own. Full solution would be to change one or the other or add a parsing solution for the results of the cURL command.

---

Multi-part message quickly explained:

There is a header of Content-Type that has the value of "miltipart/mixed;" followed by a boundary.

Example:

Content-Type: multipart/mixed; boundary=--e17f2058da4654f7

Then after that, it follows the rules as a normal http header (header ends with newline):

• Each part starts with the boundary (which appears to always start with -- even it not noted in the boundary as noted in the header
• Then normal header lines (like Content-Type of the part)
• Then a blank line at the end of the header.
• For convenience, there is a trailing boundary and newline which makes parsing easier.

---

You could then parse the header, find the boundary and then use standard tools. Suggestions for *nix for you to pipe the cURL results to:

• Milti-line SED command : eat up the text of every boundary up to and including the newline
• AWK script where you swich state (if start or in content, then enter boundary : state= header, if in header and enter newline, : state=content
• or Python, PERL, PHP, etc etc.

We can also leverage one part of HTTP and cURL to make it a little more simple. You could also set the Accept-Header for the content type and define the boundary yourself. Making it predictable makes less coding:

HTTP REQUEST:

Accept: multipart/mixed; boundary=llama

RESPONSE Header: (We can ignore since we have a predictable boundary)

Content-Type: multipart/mixed; boundary=llama

Content:

--llama
Content-Type: text/plain
X-Primitive: integer

1
--llama
Content-Type: text/plain
X-Primitive: integer

2
--llama
Content-Type: text/plain
X-Primitive: integer

3
--llama

Then using a technique as above makes parsing trivial