Add fallback for old browsers when using ?filename parameter

[auburnsummer]

When using the ?filename parameter, the IPFS gateway adds a Content-Disposition header that is RFC 5987 encoded.

For instance, if I passed ?filename=hello.zip IPFS gives this as the Content-Disposition:

content-disposition: inline; filename*=UTF-8''hello.zip

However, not all browsers/clients correctly support RFC 5987. This can lead to unexpected behaviour with the filename parameter seemingly being ignored or treated incorrectly.

The typical fallback is to provide both a filename and filename* in the Content-Disposition:

content-disposition: inline; filename="hello.zip"; filename*=UTF-8''hello.zip

It would be good if the IPFS gateway did this to increase compatibility.

I'm not super familiar with Go, but I could have a go at this?

[lidel]

Sounds like a sensible enhancement @auburnsummer, but I have some questions before you invest time in implementing this:

1. Do you have a specific app in mind that understands filename and not filename*?
   (Is this a real need, or just a theoretical concern?)
2. Do we know how browsers (eg. Safari, Chromium, Firefox) behave when they see both filename and filename*?
   (Which one is picked?)
3. My understanding is that filename will be ASCII-only:
   what type of transliteration do you have in mind?
   what happens when filename is only non-ASCII characters?

[auburnsummer]

1. At least one version of the Unity game engine's UnityWebRequest.GetResponseHeader doesn't handle filename* correctly. In my specific case, I'm working with a video game called Rhythm Doctor, which has the functionality to import custom content from the internet. It misunderstands filename* as filename.

2. I tested with the latest version of Safari, Chromium, and Firefox, which pick filename* when both filename and filename* are present. Supposedly old versions of Safari, IE8 and older, and Android versions prior to 2016 would pick filename, but I don't have the ability to test those.

3. Yes, filename will be ASCII only. Google Drive just replaces any non-ASCII characters with underscores, and I was intending to do the same thing here (e.g. hello café 你好.zip just becomes hello caf_ __.zip). The more complicated approach involves dragging in an ICU library which seems like too much for an edge case.

[lidel]

@auburnsummer sgtm, going with underscores is a way to go, makes this safe to add with low risk.
we discussed this during our weekly triage and are open to reviewing a PR if you wish to submit one 👍

[lidel]

Did not hear back from original author – I'll take this one.
(I am adding support for attachment mode, so can add this in the same PR)

[lidel]

@auburnsummer I believe #7677 does what you want :)