add options for max filesize, and max transaction size

[lday0321]

Is there any option for limiting the uploading file's max size? so that if the file size exceeds the size we set, client will get an 413 status code?

[mark-kubacki]

Thanks for the suggestion!

We'll need options max_filesize and max_transaction_size, or similar.

• If size_announced > min{max_filesize, size_transaction} → error.
• If bytes_written ≥ max_filesize and not in.EOF → error. Then, delete file? (Partial uploads (using the Range header) are currently not supported. Except for sparse files with writes to [0, n] (to the beginning of the file).)

[oliwer]

I think you can already do that with http.limits. Am I wrong?

[mark-kubacki]

Not quite. And even if – it would work like the suggested max_transaction_size.

For example, you'd like to limit the size of any picture to 10 MB, but allow N images to be uploaded in one go. With http.limits set to 50 MB (N=5) a user could upload an image >10 MB.

Furthermore, http.limits neither does care about the envelope (nested MIME multipart »headers« are counted towards the limit because everything is in the HTTP body) nor encoding (a 10 MB binary is ≈13.4 MB transferred in base64 encoding, and ≈20 MB in 7-bit-ASCII).

Third, you could create a 2 PB sparse file by setting content-length accordingly, yet indeed upload less. (VM image files are often sparse files.) A http.limit of ≪2 PB won't prevent that because all it does is count incoming bytes.

Anyway, I have started working on this. caddy.upload is not my top priority project, though.

[mark-kubacki]

Implemented, and will be part of the next version, which I intend to submit soon so it can be downloaded through Caddy's homepage.

You can test it using the build artifact from CI/CD, if you like. Click on the build: success button, which is a link to Gitlab.

There's a degree of freedom regarding error codes with incomplete multipart uploads, and whether to keep rejected uploads anyway, skip the offending file, or the entire transaction (all files up to including aforementioned one).—If you don't like the currently implemented behaviour, now is the time to request changes.