Opened 18 years ago
Closed 16 years ago
#4148 closed (fixed)
Inclusion of Middleware to fix IE VARY bug
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Keywords: | pdf, ie, middleware | |
Cc: | axiak@…, axisofentropy@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There is a bug in Internet Explorer, described in http://support.microsoft.com/kb/824847/en-us?spid=8722&sid=global, where Vary headers will break certain applications.
One easy way to create this bug is to generate a !PDF and loading the page in IE.
This can either go in the core
or in
contrib
, but I'm afraid it will be lost if it stays on a site like djangosnippets, where it could really help people who plan to generate PDFs.
Attachments (7)
Change History (25)
by , 18 years ago
Attachment: | 5065-fix_ie_error_bug__for_4148.diff added |
---|
comment:1 by , 18 years ago
Needs documentation: | set |
---|
comment:2 by , 18 years ago
Needs documentation: | unset |
---|
comment:3 by , 18 years ago
Summary: | Inclusion of Middleware to fix IE VARY bug → [patch] Inclusion of Middleware to fix IE VARY bug |
---|
comment:4 by , 18 years ago
Summary: | [patch] Inclusion of Middleware to fix IE VARY bug → Inclusion of Middleware to fix IE VARY bug |
---|
comment:5 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:6 by , 18 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Design decision needed → Accepted |
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).
by , 18 years ago
Attachment: | 5078-fix_ie_vary_bug_core__for_4148.diff added |
---|
Take 2: This file alters the BaseHandler to do it and adds a setting to disable it if one wants.
by , 18 years ago
Attachment: | 5078-fix_ie_vary_bug_core__for_4148_2.diff added |
---|
Take 2: This file alters the BaseHandler to do it and adds a setting to disable it if one wants. This patch is better.
comment:7 by , 18 years ago
Keywords: | ie added; iesux removed |
---|
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 (!).
comment:8 by , 18 years ago
Cc: | added |
---|
comment:9 by , 18 years ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Thanks Michael, looks pretty clean to me.
comment:10 by , 18 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
Discussed a slightly less odd way to implement this on IRC
by , 18 years ago
Attachment: | 5079-fix_ie_cache_bugs.diff added |
---|
Cleaned the patch a little bit...added fix for content-disposition
by , 18 years ago
Attachment: | 5079-fix_IE_cache_bugs_2.diff added |
---|
Cleaned the patch a little bit...added fix for content-disposition...take two
comment:11 by , 18 years ago
Triage Stage: | Accepted → Design decision needed |
---|
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.
by , 16 years ago
Attachment: | 7737-fix_ie_cache_bugs_3.diff added |
---|
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.
comment:12 by , 16 years ago
Triage Stage: | Design decision needed → Accepted |
---|
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.
comment:13 by , 16 years ago
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:
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.
comment:14 by , 16 years ago
Cc: | added |
---|
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:
- 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
- Point your urlpatterns at this view, maybe like
urlpatterns = patterns('', (r'^foo.xls', 'views.django_ticket_4148_sample_with_Vary'), )
- Make sure an Excel file exists at the path shown above.
- Visit the URL in Internet Explorer (6 or 7)
- 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
comment:15 by , 16 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
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.
comment:16 by , 16 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
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.
comment:17 by , 16 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
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.
comment:18 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The middleware. It includes the documentation.