See this bug report for more details.
Judging from serverside_capture.txt (which contains a fragment of the HTTP traffic captured on the server side using a packet sniffer), when the bug is triggered it looks like OrientDB returns a correct value for the Content-Length
header but writes the whole response buffer exactly twice and it's not the buffer left from a previous request since my test case alternates two different SELECT queries. Unsurprisingly this seems to break cURL because, when it's able to keep the underlying connection open, it reads spurious data from the previous response instead of the expected HTTP headers.
As far as I can tell, but I can't yet be sure of what I'm going to write, this bug might not even be actually related to the practice of reusing the underlying connection. When a new connection is used for each new request, cURL reads up to $CONTENT_LENGTH
bytes fro