Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#31082 closed Bug (invalid)

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

Reported by: David Evans Owned by: nobody
Component: HTTP handling Version: 3.0
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (3)

comment:1 by Carlton Gibson, 5 years ago

Resolution: invalid
Status: newclosed
Type: UncategorizedBug

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.

comment:2 by David Evans, 5 years ago

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.

comment:3 by Carlton Gibson, 5 years ago

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. 😉

Note: See TracTickets for help on using tickets.
Back to Top