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
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 http://10.1.1.1:8090/app/programs?clientId=5350 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
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.
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.
It's fixed in 1.8.