Wt

I've tried this on Debian 10 and Ubuntu 18.04.4 amd64 systems.

Yes, you're supposed to increase that limit to allow for larger files.

Roel Standaert wrote:

Yes, you're supposed to increase that limit to allow for larger files.

Thank you for that insight. My question, however, is why the upload fails for a 9 MB file when the limit is sufficiently large?

That's probably because there's always going to be some overhead. The file size may be 9 MB, but the actual request will be larger than that.

Roel Standaert wrote:

That's probably because there's always going to be some overhead. The file size may be 9 MB, but the actual request will be larger than that.

Ok, I increased the value by an order of magnitude, and still get the same error:

2020-Jun-12 07:29:23.440] 26690 - [error] "Http::ResponseContinuation: WebWriteEvent::Error"

I think this is what is called a bug.

Ah, I think I misunderstood you. Your issue is not the size limit, but something else. It's not unusual for us to have uploads that large though, so it's odd.

Roel Standaert wrote:

I tried to reproduce your issue with the widget gallery (modified wt_config.xml to set max-request-size to 10000), and I'm noticing no issues with that. Maybe this is platform or browser specific? I don't know under what circumstances you're getting this issue.

I tested it with Firefox and Chrome on Ubuntu 18.04.

I must apologize - after compiling the Widget Gallery and using the appropriate config, your example does indeed work. I will look closely at the example code to see what is different.

In the documentation it is unclear the purpose of WFileUpload::setFileTextSize(). A comment in "FileUpload.cpp" claims it limits file size, but this is clearly not the case. Could you please clarify the purpose of this function?

That refers to the size of the input in (approximate) number of characters. It's like WLineEdit::setTextSize.

I once had a similar problem when using chrome as a browser. I did not make any notes about that but i think to remember it had something todo with a barrierer like thing (to signal end of file?) which also happened to be part of the file.

Marco Kinski wrote:

I once had a similar problem when using chrome as a browser. I did not make any notes about that but i think to remember it had something todo with a barrierer like thing (to signal end of file?) which also happened to be part of the file.

Thanks for chiming in. I have this working now, but I'm not exactly sure what fixed the problem. I changed one value from the default (128) in the configuration which seems to have influence:

100000