On an ticket, I try to append a file larger than 1 MB to an replay e-mail (with smaller files, it works).
Expected behavior:
The same as with files smaller than 1 MB, that the file gets attached to the e-mail.
Actual behavior:
Stuck in the middle of uploading with HTTP status 413 Payload Too Large, making the JavaScript program on the client run into an error on JSON.parse().
Steps to reproduce the behavior:
Receive a ticket, reply to the mail and attach a file larger than 1 MB.
Can you please provide logfile of nginx and Zammad in the moment this issue appears?
Personally I don’t think we can do anything about this (it works on my machines ™, but I’d still love to checkI)
Even if I simulate the request on command line with curl, curl shows that:
> POST /api/v1/upload_caches/703429498 HTTP/1.1
> Host: support.whatsasolution.com
> User-Agent: curl/7.66.0
> Accept: */*
> Content-Length: 2886071
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 413 Request Entity Too Large
< Server: nginx/1.10.3
< Date: Mon, 14 Oct 2019 10:51:56 GMT
< Content-Type: text/html
< Content-Length: 199
< Connection: close
<
<html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
Oddly enough, the access log shows HTTP status 200, so I cannot grasp the problem well.
The error response can also be seen in the Firefox developer tools.
My best guess is that either Zammad (that is primarily Ruby) also has a setting like PHP’s upload_max_filesize that has to be adapted (I know nothing about Ruby); or that my configuration somehow struggles with the HTTP request header line Expect: 100-continue (but why should all Web browser and curl fail?).
I turned this to 50 MB too, but the error remains.
I, [2019-10-14T13:48:10.069922 #32743-47193844765400] INFO -- : Started POST "/api/v1/message_send" for <IPADDR> at 2019-10-14 13:48:10 +0200
I, [2019-10-14T13:48:10.078871 #32743-47193844765400] INFO -- : Processing by LongPollingController#message_send as JSON
I, [2019-10-14T13:48:10.078971 #32743-47193844765400] INFO -- : Parameters: {"data"=>{"event"=>"login"}}
I, [2019-10-14T13:48:10.084644 #32743-47193844765400] INFO -- : client(8399884603) new client connection
I, [2019-10-14T13:48:10.087115 #32743-47193844765400] INFO -- : Completed 200 OK in 8ms (Views: 0.1ms | ActiveRecord: 3.6ms)
The progressbar jumps up to 100%, but remains like this. Usually, it should be replaced by the filename and filesize when finished.
Screenshot below, sorry that it is in German, but the problem does not dependent on the language, it is just the progress bar without the filename. Also, the Firefox dev tools are visible.
I forgot that there was another nginx as reverse proxy before… Please forget about my stupid question. Of course, both nginx instances should have client_max_body_size set to the same value.
I forgot that there was another nginx as reverse proxy before… Please forget about my stupid question. Of course, both nginx instances should have 