Inclusion of Middleware to fix IE VARY bug

The middleware. It includes the documentation.

This probably shouldn't be middleware. It's something that has to always be done to the response, because it's broken all the time. Because of the impact, this fix needs to be included. We can also leave out the Microsoft bashing in the initial docstring (although the reference to the bug we are fixing should stay).

Take 2: This file alters the BaseHandler? to do it and adds a setting to disable it if one wants.

Take 2: This file alters the BaseHandler? to do it and adds a setting to disable it if one wants. This patch is better.

Okay, I put it in the BaseHandler in what it seems a fairly clean way. If you want to move the actual response processing out of that file, you're free to do so. Also, sorry for putting [patch] in the summary, I thought that was standard (!).

Thanks Michael, looks pretty clean to me.

Discussed a slightly less odd way to implement this on IRC

Cleaned the patch a little bit...added fix for content-disposition

Cleaned the patch a little bit...added fix for content-disposition...take two

The new update is very much like the other version, without a settings variable. It also includes a fix for a bug in IE whereby if you use Content-Disposition and either Pragma: no-cache or Control-Cache with either no-cache or no-store IE will not let you download it.

It's been a year, and this bug persists. It prevents documented examples like http://www.djangoproject.com/documentation/request_response/#telling-the-browser-to-treat-the-response-as-a-file-attachment I've modified the last submitted patch, bringing it in line with the newer version of the HttpResponse class.

This has been accepted several times; I can't see anything that needs an additional design decision. However, I don't have ready access to IE to validate the fix, so someone else will need to test the patch before it is ready for checkin.

I have machines with IE (W2K with IE6 and XP with IE7) so I thought I could test the fix. However I cannot recreate the problem. Using trunk r7739 (development server) and following the example at:

http://www.djangoproject.com/documentation/request_response/#telling-the-browser-to-treat-the-response-as-a-file-attachment

either specifying no Vary header or including a Vary header matching the one at:

http://support.microsoft.com/kb/824847/en-us?spid=8722&sid=global

I see no problem on either of my Windows machines. I choose "Open" from the popup and Excel opens with the file supplied in the response. Also tried a PDF and ran into no errors opening that either. If someone could tell me exactly what I need to do to hit the error, I'll try again to test the fix.

Ah, there's a little more needed to reproduce this bug. Django does not always attach a Vary header to every HttpResponse. In my case, the sessions middleware was automatically adding one to a generic.list_detail view (although it wasn't really appropriate, see also bug #3586). So to reproduce this easily, make sure that your HttpResponse does include a Vary header by using a decorator:

1. create a views.py like so:

from django.http import HttpResponse
from django.views.decorators.vary import vary_on_cookie

@vary_on_cookie #explicitly ensure this HttpResponse includes a Vary header
def django_ticket_4148_sample_with_Vary(request):
    fileHandle = open('/var/www/static/foo.xls', 'r')
    my_data = fileHandle.read()
    response = HttpResponse(my_data, mimetype='application/vnd.ms-excel')
    response['Content-Disposition'] = 'attachment; filename=foo.xls'
    return response

2. Point your urlpatterns at this view, maybe like

urlpatterns = patterns('',
    (r'^foo.xls', 'views.django_ticket_4148_sample_with_Vary'),
)

3. Make sure an Excel file exists at the path shown above.
4. Visit the URL in Internet Explorer (6 or 7)
5. My IE6 spits out garbage when trying to view a .xls file like this. For other Content-Types like .pdf IE can't open their temporary file, and .odt is even weirder. Firefox works fine.

It's possible that some apache or python handler configurations could cover this up for IE users, so I'd like to hear from people running other distros.

My implementation, running on mod_python on Gentoo, is viewable here, for anyone with IE: http://entropyindustries.com/foo.xls

OK, the key difference between what I was trying and your setup seems to be the fact that I was using the development server and you are using Apache. There must be something else that Apache is doing that the development server does not do that triggers the error, since no matter what I tried I could not recreate with the development server. So I tried again, this time using Apache as my server and then I could recreate the problem with both IE6 & IE7. Applying the patch 7737-fix_ie_cache_bugs_3.diff fixed the issue for both browsers. Promoting to ready for checkin since Russell's last comment seems to indicate all that was needed was testing/verification, which I've now done.

Updated and corrected(?) patch

I've cleaned up the patch a bit, added some extra robustness, and moved the code to the correct locations, since we already have some "compulsory middleware" now.

Can somebody give this a quick check (if you're using IE, actually run the code)? I'm a bit tired at the moment and may easily have made some kind of bozo error. It doesn't crash when I run things, but, then again, I don't have IE -- or even Windows -- either. Can be moved back to "ready for checkin" when it's been tested.

Verified 4148-fixed.diff using IE6 & IE7. Verified failures on r7852 without the patch, fixed by applying the patch. Verified headers from Firefox were unaffected by the patch (Vary still present after patch whereas it's gone for IE6/IE7). Didn't attempt to track changes to the Cache-Control header though.

(In [7856]) Fixed #4148 -- Changed the way attachments are served to IE to avoid some caching and header-related bugs there. Only comes into play when Internet Explorer is the user-agent.

Patch from Michael Axiak, with testing from Axis_of_Entropy and Karen Tracey.