E-Mail attachment size

  • Used Zammad version: 3.1.0
  • Used Zammad installation source: source
  • Operating system: Debian Linux 10.0
  • Browser + version: Firefox 69.0.2, Chromium 77.0, Epiphany 3.34.1
  • Web Proxy Server: nginx 1.14.2

In the virtual host config of Zammad, it says:

   client_max_body_size 50M;

(I already tried unlimited, too).

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)

The error log does not show anything, and the access log shows only one request during that:

<IPADDR> - - [14/Oct/2019:12:50:18 +0200] "POST /api/v1/message_send HTTP/1.0" 200 26 "https://support.whatsasolution.com/" "Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"

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
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>

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’m missing the Zammad-Logfile here, but anyway.
Up to now I didn’t suspect you to turn the maximum attachment sizes to 1MB or so.

By default, Zammad allows attachments up to 10MB.
The setting can be found within the admin settings -> email (channel) -> settings tab

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.

:scream: 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.

1 Like

No worries, glad you could solve your issue :smiley:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.