Error 413: Entity Request Too Large

Help
1

1. Caddy version (caddy version):

2.2.0

2. How I run Caddy:

Fired from BATCH file. I know it should be a service, and I will make that happen soon. This server is still in development and I wanna see everything work before I harden security.

a. System environment:

I’m using Aurora Files on a self hosted server. (GitHub - afterlogic/aurora-files: Aurora Files is an open-source file storage platform.) It’s a lightweight PHP application I’m running under IIS. Setup is straightforward.

Windows 10 LTSC
IIS W/ PHP
Website on port 301
Caddy reverse proxy → 301

b. Command:

caddy start

d. My complete Caddyfile or JSON config:

files.visualetl.com {
@localnet {
not remote_ip 192.168.1.1/16 12.246.126.122/32 68.225.124.230/32 99.49.222.215/32
}
respond @localnet “Access denied” 403 {
close
}
reverse_proxy 192.168.1.128:301
}

3. The problem I’m having:

During upload of large files, receiving error “413: Request Entity Too Large” in console, and upload fails.

4. Error messages and/or full log output:

receiving error “413: Request Entity Too Large”

5. What I already tried:

In order to isolate this away from IIS, I shut down Caddy, connected directly to the website via IIS, and large uploads start working fine.

I have edited the PHP.ini file to allow large files like so:
post_max_size: 2000M
upload_max_filesize: 2000M

I have adjusted IIS properties as follows:
MaxRequestEntityAllowed: 4294967295
uploadReadAheadSize: 2147483647

6. Links to relevant resources:

Aurora Files:

Thanks in advance!

2

Hmm. Caddy itself isn’t responding with 413 (i.e. nothing in the code makes that happen). It’s unclear where that’s happening.

Please add the following to the top of your config and try again, it should reveal some more information in your logs about the proxy request

{
	debug
}
3

Ok so I put the Caddy output on one screen, then I pulled up Aurora (my file sharing site) on the other screen. Whenever I dropped a file into Aurora, Caddy output this:

DEBUG http.handlers.reverse_proxy upstream roundtrip {"upstream": "192.168.1.128:301", "request": {"remote_addr": "68.225.124.230:62428", "proto": "HTTP/2.0", "method": "POST", "host": "files.visualetl.com", "uri": "/?/Api/", "headers": {"Accept-Language": ["en-US,en;q=0.9"], "X-Forwarded-For": ["68.225.124.230"], "Content-Type": ["multipart/form-data; boundary=----WebKitFormBoundaryk3w4sZ1A5h8VmeAB"], "Accept": ["*/*"], "Referer": ["https://files.visualetl.com/"], "Accept-Encoding": ["gzip, deflate, br"], "Origin": ["https://files.visualetl.com"], "Sec-Fetch-Site": ["same-origin"], "Sec-Fetch-Dest": ["empty"], "X-Forwarded-Proto": ["https"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"], "X-Client": ["WebClient"], "Content-Length": ["67817203"], "Authorization": ["Bearer UB4R8mox1qQ3xMqrrtD-WqyM8-p6X1AQ2QqGgbWpRthtsKTzBMz-jmz16vBybecHXRNc4a-mMn1sP9YKe48_wZSHX-Z-HVjyS_9c1Y8V7oJtn_-16u8TpU8qq-oUDfhvU6FZyNhd33Pwbuz5szS2gPa9paK6sqBzxdkiT5D_FASteYyep31GhjFYDoLvKAAchAYJTNTXSOCm46-1Ft0ILDbSeQ2FKhJ3Fsr_gHEqilganH3NBpmnO2R-M7cb-snQO0rIhydBo2I1r9jzZctvIXtijv0ijlxMaXkTSA"], "Sec-Fetch-Mode": ["cors"], "Cookie": ["_ga=GA1.2.1707042234.1602193923; AuthToken=UB4R8mox1qQ3xMqrrtD-WqyM8-p6X1AQ2QqGgbWpRthtsKTzBMz-jmz16vBybecHXRNc4a-mMn1sP9YKe48_wZSHX-Z-HVjyS_9c1Y8V7oJtn_-16u8TpU8qq-oUDfhvU6FZyNhd33Pwbuz5szS2gPa9paK6sqBzxdkiT5D_FASteYyep31GhjFYDoLvKAAchAYJTNTXSOCm46-1Ft0ILDbSeQ2FKhJ3Fsr_gHEqilganH3NBpmnO2R-M7cb-snQO0rIhydBo2I1r9jzZctvIXtijv0ijlxMaXkTSA; filemanager=kh9hhl0fk7o9vru2dbce59fdnk; session_id=259b2b3a08ffcde0411faae9d489c3a3; email_id=cwmpensacola%40gmail.com"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "files.visualetl.com"}}, "duration": 0.001, "headers": {"Content-Type": ["text/html"], "Server": ["Microsoft-IIS/10.0"], "Date": ["Fri, 06 Nov 2020 20:23:20 GMT"], "Content-Length": ["67"]}, "status": 413}

4

That shows that the upstream you’re proxying to is responding with 413.

:man_shrugging:

5

Welp that’s good in the sense that I don’t have to continue diagnosing Caddy then. Thanks for your help!

6

Posting for posterity: I have solved this issue using the following IIS configuration -

IIS → Click the website in question → click Request Filtering → click the Headers tab → click Add Header → Configure this screen using the instructions below:

In the “Maximum allowed content length (Bytes)” field, enter this number, or something much larger than what is already in there:

2147483647

That fixed the upload size issue for me.

Some back story: When I originally posted this, I had ruled out IIS being the problem, stating that I had isolated the problem to Caddy - in fact, the large upload worked fine while no SSL was engaged. Once the SSL engaged, IIS began presenting this problem, and since I get my SSLs from Caddy, I wrongly assumed the problem was with Caddy.

2 Likes
7

Double edit: I think the maximum header size in IIS is 4294967295, which I think is dead-on 4 Gb, and works with my configuration. I just uploaded a 3.6 Gb CD image and it worked as expected.

8

This topic was automatically closed after 30 days. New replies are no longer allowed.