Tags

Earlier this week, I needed to upload some files to a community for a test. As I was uploading them, I noticed that some repeatedly failed. Not having the time to investigate that issue, I put it aside until it came around again today when a colleague indicated she was working on an issue with HTTP 413 failures when uploading files greater than 1 MB. Returning to my prior tests and digging a little deeper this time, that was exactly what I was seeing, too.

After poking around a bit, we found that both environments have NGINX configured as a proxy for use with Customizer. (Editorial: Customizer is awesome, and you should definitely check it out!) So why is that important?

NGINX has a configuration parameter named client_max_body_size that caps the maximum content length. If not set, this defaults to 1 MB, the exact size at which the issue occurs. You can spot this by looking in your NGINX access.log. Here's what I had in mine:

What makes this particularly tough to diagnose is that the request never makes it past NGINX, so you won't even see it hit IHS. Fortunately, the fix is quite simple: just add the client_max_body_size parameter to /etc/nginx/nginx.conf and restart NGINX. I chose the http context, like this:

Setting it to zero disables checking the request body size, which is a good option for Connections, since it allows all of the size limits to be handled by the various app configurations. As a bonus, I've included my log format string, which I find much more helpful than the out-of-the-box configuration.