Zammad sets an invalid Content-Type header for files with spaces in the filename

[timoschwarzer]

Used Zammad Version

6.3

Environment

• Installation method: Helm
• Operating system (if you're unsure: cat /etc/os-release ): N/A
• Database + version: Postgres 15.4.0
• Elasticsearch version: 8.12.0
• Browser + version: Chrome 124.0.6367.201 and Firefox 125.0.3

Actual behaviour

When downloading a ticket attachment with a space in the name, the Content-Type header is set to an invalid value. For example, if the file is called My File.pdf, the Content-Type header is set like this:

Content-Type: application/pdf; name="My

This is a problem when operating Zammad behind a reverse proxy, such as Traefik 3.0, which will cancel the request.

Currently, this prevents us to download any attachments that contain spaces in their file names.

Expected behaviour

The Content-Type header should be valid. As far as I can see from the MDN docs, name is not something you are allowed to set in the Content-Type header anyways. Regardless of that, the missing closing quote is syntactically incorrect.

Steps to reproduce the behaviour

Create an attachment with a filename containing a space. Then look at the request when downloading that attachment. (It's easiest with pictures, since they won't be opened in a new tab and thus you can see the request in the Network tab in the Dev Tools)

Support Ticket

No response

I'm sure this is a bug and no feature request or a general question.

yes

[timoschwarzer]

I took the day to investigate further on this and it seems to be a rabbit hole:

• The name="my filename.pdf" part of the Content-Type header does not come from Zammad itself, but is directly copied from the incoming email.
  → That means that this issue does only happen for attachments that arrived by email.
• I have tried different MTAs and Email clients, all do append name="my file name.pdf" to the Content-Type header

The core issue here lies in Rails' (in my opinion completely messed up) way of parsing Content-Type headers, which breaks in the slightest more advanced (but valid) cases, such as having quoted parameters.

Fixing this behavior in Rails is a bigger undertaking and will probably break stuff. I've seen from the test cases, that Rails currently makes assumptions that do not make sense to me and don't seem to adhere to the RFC at all.

I know that this is technically not an issue in Zammad itself, but since a fix in Rails will at least take a while, my suggestion would be to strip away all parameters except charset in Content-Type headers when receiving attachments via email in Zammad. What do you think?