Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content-Disposition header with inline disposition in Django 3.0 breaks in Safari #240

paltman opened this issue Dec 6, 2019 · 3 comments


Copy link

@paltman paltman commented Dec 6, 2019

I can't determine if this is something that needs to be addressed in Whitenoise or in Django but in Django 3.0, a Content-Disposition header is being added as inline and that is causing Safari to not parse it.

This new header was added in de4832c49b8a8cf00b2d602ab4d10c4ca69627bd.

I can verify this works by adding this middleware before the WhiteNoiseMiddlware in my

def strip_content_disposition(get_response):
    def middleware(request):
        response = get_response(request)
        del response['Content-Disposition']
        return response
    return middleware

Obviously that's not a good solution for this, but I'm not sure what is or even if this is a Whitenoise issue or a Django issue.

paltman referenced this issue in django/django Dec 6, 2019
Copy link

@paltman paltman commented Dec 6, 2019

Ended up using a setting built for this:

def strip_content_disposition(headers, path, url):
    headers["Content-Disposition"] = ""

WHITENOISE_ADD_HEADERS_FUNCTION = strip_content_disposition

eliminates the need for the middleware.

Thanks for the suggestion, @jacobwegner

@paltman paltman closed this as completed Dec 6, 2019
evansd added a commit that referenced this issue Dec 10, 2019
Django 3.0 adds a default Content-Disposition header to all FileResponse
instances. Where the response isn't flagged as an attachment this header
has the form `inline; filename="<filename>"`. See:

This header causes problems with Safari (see #240 and #241) so we want
to make sure we don't send it. Looking at the code for FileResponse I
can see that Django is also setting other default headers. These will
generally be overwritten by WhiteNoise, but they cause unnecessary file
accesses and provide more possibilities for errors.

This patch creates a tiny wrapper around FileResponse which disables the
setting of any default headers.
Copy link

@peterflat peterflat commented Dec 19, 2019

Just a note that I am using Django 2.2 with whitenoise and this is an issue for Safari 13. The
WHITENOISE_ADD_HEADERS_FUNCTION Solution above works like a charm.

Copy link

@evansd evansd commented Dec 19, 2019

@peterflat That's very strange as the code which causes this problem wasn't added until Django 3.0 so probably you're hitting a different issue. In any case, you don't need the workaround if you use WhiteNoise v.5.0 or above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

3 participants