Maximum message length when using VIP


I'm experiencing a service-breaking bug/issue that involves an HTTP maximum message length error.

This is the CURL command I am running, with obvious sanitation:

curl -X GET -H "X-Parse-Application-Id: <ID>" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: <TOKEN>" "https://SITEADDRESS/parse/classes/Game?where=%7B%7D&limit=400&skip=0&order=-createdAt,-createdAt"

It returns a JSON message as expected but once it reaches that maximum length (not sure what it is), I get this error (size is an example) from CURL:

(18) transfer closed with 130318 bytes remaining to read

and then the message is cut off.

If I use a smaller CURL, such as limit=40 rather than limit=400 in the URI, the data returns successfully.

This message limit seems to be at ~65k


Oleksandr Shevchuk
August 23, 2016, 3:04 PM

I have the very similar issue.

everything is Ok when I curl my app directly http://10.XX.XX.X:29222/app/programs?clientId=5350
but when I curl via VIP address in most cases, I receive only part of JSON and reset by peer message:

  • Recv failure: Connection reset by peer

  • Closing connection 0
    curl: (56) Recv failure: Connection reset by peer

Aaron Dean
August 23, 2016, 3:15 PM

I wanted to add that if you CURL directly to the app, it works fine for me as well. It doesn't cut off the message.

Another thing I noticed when using Postman is that http-keep-alive is not in the Connection properties if I use the VIP, but it DOES exist when hitting the app directly. Adding 'options http-keep-alive' in HAProxy frontend/backend has no effect.

Aaron Dean
August 24, 2016, 2:47 PM

I created a new cluster (1 Master, 1 Public, 1 Private) CentOS 7.2, Docker 1.11.2, DC/OS 1.8.1 and tested, appears to have solved the issue. Will verify with our product team to find out if there is a new limit or if this was simply a 1.7 bug.

Sargun Dhillon
August 24, 2016, 3:13 PM

It's fixed in 1.8.

Won't Do


Sargun Dhillon