New `Content-Disposition: inline` header in FileResponse causing issues on Safari

[David Evans]

Django 3.0 introduced a new default Content-Disposition: inline header on FileResponse instances. I've had reports that Safari is unable to load JavaScript files served with this header. Issue ​#241 explains in more detail and links to a reproducing example. (I don't have access to Apple hardware right now so I'm unable to add any detail myself.)

I've been able to ​work around this easily enough in WhiteNoise, but I thought it was worth reporting in case it causes issues elsewhere.

[Carlton Gibson]

Hi David.

Thank you for opening the issue here. Very interesting.

I'm going to initially close this as Invalid, but happy to continue discussion. (!!!)

Summary: I think Whitenoise should be passing the filename parameter to FileReponse, with the original filename, maybe with the checksum component, but definitely with the original .js extension, rather than the .gz extension that gets added during the collect static phase.

Note ​the `FileResponse` docs:

If open_file doesn’t have a name or if the name of open_file isn’t appropriate, provide a custom file name using the filename parameter.

Doing this, results in Safari loading the page correctly. i.e. it's not the filename parameter causing the issue, but the .gz, which I'm guessing Safari takes as invalid for JS...?
(With the original filename in place, Safari still picks up the content encoding as gzip and loads the file correctly.)

What do you think? C.

[David Evans]

Thanks Carlton, that's really helpful. I understand what's happening now and I can see it's not a Django bug.

I'm still slightly surprised by Safari's behaviour here. Given that we're sending the correct Content-Type and Content-Encoding headers I don't see why the filename should make any difference.

I think I'll stick with the workaround I currently have for WhiteNoise though as I prefer to maintain control over exactly what headers get sent.

Thanks again.

[Carlton Gibson]

OK 👍

I'm still slightly surprised by Safari's behaviour here. Given that we're sending the correct Content-Type and Content-Encoding headers I don't see why the filename should make any difference.

Hmmm. Yes. I don't see why the browser care what I call the file at all, but... 🤷‍♀️

Thanks again for reporting the issue. Let's keep the communication channels open. 😉