I'm not sure how it is done right now but apparently non-ascii characters are to be included, they should be added to the filename* field with the RFC 5987 encoding

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#syntax

You may want to avoid percent escape sequences in filename, because they are handled inconsistently across browsers.

I'm not sure how it is done right now but apparently non-ascii characters are to be included, they should be added to the filename* field with the RFC 5987 encoding

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#syntax

You may want to avoid percent escape sequences in filename, because they are handled inconsistently across browsers.

@lajp I'll take a look. We are using a higher level abstraction with FormData and Fetch, that should do the right thing automatically...

I found a potential cause for this. Apparently multer, the crate used by axum::extract::Multipart doesn't support the filename*-field: rwf2/multer#52

We could also just slugify the original filenames and strip special characters as a workaround, I doubt that would affect any invoices negatively 🤔 Could do it in similarly like we do with heading IDs for rich text