According to RFC-7578 the Content-Disposition filename* parameter in multipart MUST NOT be used

[tts-sdrissen]

Hi there,

I have an old ASP.NET 2 server, where I need to make requests to. I found other Flurl users have a hard time doing this, because of the "not quoted filename": #327 I did as suggested by @tmenier, and added quotations by myself when calling Flurls AddFile. But this lead to another issue, because now, the filename parameter contains escaped quotation: `Content-Disposition: form-data; name="file"; filename="test.csv"; filename=utf-8''%22test.csv%22`

@tmenier said 2019 in #404, that filename* is allowed according to RFC-6266, but in RFC-7578 from 2015 it says:

NOTE: The encoding method described in [[RFC5987](https://www.rfc-editor.org/rfc/rfc5987)], which would add a "filename*" parameter to the Content-Disposition header field, MUST NOT be used.

English is not my native language, but I understand, that filename* MUST not used anymore. Like it is forbidden.

I don't even ask for the general removal of the "filename" parameter, but I need something to deactivate that. If I forge the request, and remove filename parameter - everything is okay.

I know, I know... I should stop "coping with the past" and bury ASP.NET 2 next to Windows XP - but it is a third party software and I cannot throw it away... I just need to make it work.

I tried cURL 8.4.0 - it does not use filename* at all, even if there are non-US-ASCII letters (see the letter Ä): Content-Disposition: form-data; name="file"; filename="täst.csv"

Even if I use very not non-US-ASCII letters - cURL does not use filename* parameter: Content-Disposition: form-data; name="file"; filename="某物.csv"

I am very grateful for any suggestions.

[tmenier]

First, sorry for the looooong delay with this one.

Second, I think you might be correct. @cremor has had some great insights regarding these sorts of issues, any opinion on this one? The short of it is, filename* appears to be a valid thing in most contexts, but explicitly forbidden in the context of multipart/form-data.

The even-shorter of it is, do you think it's safe to remove this line?

https://github.com/tmenier/Flurl/blob/4f28752be2b2d93b9e91119f4f39ecacc395399f/src/Flurl.Http/Content/CapturedMultipartContent.cs#L142

[cremor]

Sorry, I don't have any insight in this topic.

[tmenier]

@cremor Thanks for responding and my apologies, I might have been thinking of someone else but can't remember their handle!

@tts-sdrissen I suspect this is a safe and correct fix, I'll get it on the near-term roadmap.