Does anyone know if there’s a limitation on the maximum length for the body in a POST to the REST API?
Here’s the scenario:
- A POST is sent to a custom method with a partial data set and it all goes through correctly.
- The same call is made with the full data set and a 400 error is returned with the message “Parameter ds is not found in the input object” (the ds parameter does exist).
- The whole data set is split into pieces (possible in this case because it’s just a collection of independent rows) and then sent through with no issues.
It seems like the data set is being truncated when sent whole and so the server-side parsing fails. Has anyone else run into this? Is there a setting that can be changed to accommodate larger data sets? I can send the batched sets but overall performance starts to go downhill because of the overhead of multiple calls/responses.
Maybe helpful…sounds like default IIS has a 200kb limit by default. What size data are you sending
Also that answer is from 2010 so I wonder if anything has changed on that front
That’s certainly a place to start looking - I was too focused on it being internal to Epicor’s REST implementation. Thanks for pointing that out.
It’s quite a bit bigger than 200KB. I just saved it and it’s about 8.5MB.
I’m looking at different settings on my IIS and the Request Filtering settings look like this for the Default Website:
Tested and confirmed!
Apparently it’s twofold. There’s the Request Filtering Maximum Allowed Content Length which was already set to 30000000 B (30MB) and shouldn’t have stopped anything. AND there’s the maxRequestLength which defaults to 4096 KB and what was probably truncating my incoming data set and causing the error.
This post does a good job of explaining it and provides screenshots of how to change these values through IIS’s UI.
I increased both values to 50 MB and the large set went through the first time! It took a little while to work through it all, but was still significantly faster than batching the process. Thanks for the push in the right direction @Aaron_Moreng.