Opened 15 years ago

Closed 15 years ago

Last modified 12 years ago

#10630 closed (fixed)

[PATCH] GZipMiddleware does not handle all MSIE issues.

Reported by: Sebastian Noack Owned by: nobody
Component: HTTP handling Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There is a hook in the GZipMiddleware which bypass compression for javascript and pdfs, if user agent is MSIE. But I had to note that there are more situations where MSIE sucks. For example zip archives are not decompressed by Internet Explorer, instead MSIE saves a gzip compressed zip archive (which you can't open), even when using the latest version of Internet Explorer. So because of MSIE sucks so much and there might be another cases where compression leads to problems, I think the best aproach is to bypass compression for each non-text content type, when using MSIE. I have written a patch for that, see attachment.

Attachments (1)

MSIE-fix-in-GZipMiddleware.patch (879 bytes ) - added by Sebastian Noack 15 years ago.

Download all attachments as: .zip

Change History (9)

by Sebastian Noack, 15 years ago

comment:1 by thatch, 15 years ago

Component: UncategorizedHTTP handling
milestone: 1.1
Triage Stage: UnreviewedAccepted

comment:2 by Malcolm Tredinnick, 15 years ago

This isn't a particularly great solution, since it's no doubt throwing out a few babies with the bathwater, but I agree we probably have to be a bit conservative here. Will apply this patch and, in the future, we can add more whitelisted exceptions if they seem worth it. We also probably need a way to indicate "don't gzip this", down the track, so that the HttpResponse creator can avoid this middleware piece for particular pieces of content (trying to gzip a zip archive is pretty pointless, for example).

comment:3 by Malcolm Tredinnick, 15 years ago

Resolution: fixed
Status: newclosed

Fixed in r10541.

comment:4 by Malcolm Tredinnick, 15 years ago

(In [10542]) [1.0.X] Fixed #10630 -- Be even more conservative in GZipMiddleware for IE.

Patch from sebastien_noack.

Backport of r10541 from trunk.

in reply to:  2 comment:5 by Sebastian Noack, 15 years ago

Replying to mtredinnick:

We also probably need a way to indicate "don't gzip this", down the track, so that the HttpResponse creator can avoid this middleware piece for particular pieces of content (trying to gzip a zip archive is pretty pointless, for example).

Yo can do that in the vie function by striping 'gzip' from the request's HTTP_ACCEPT_ENCODING header. Maybe we should introduce a decorator for that.

comment:6 by Malcolm Tredinnick, 15 years ago

That won't work easily. Wildcards ("*") are permitted in the Accept-Encoding header. So we'd end up having to add a ";q=0" piece to the header (and then remembering to process preference values later on). Also, Accept-Encoding is an optional HTTP header, so we might have to create on anew.

Trying to override some server-provided information for side-effects down the processing track is going to be more effort than a more direct internal data structure or other indicator in this case.

comment:7 by Sebastian Noack, 15 years ago

I agree, but wildcards aren't handled by the GZip middleware at the moment anyway. The gzip middleware just looks for the string "gzip" in HTTP_ACCEPT_ENCODING.

comment:8 by Jacob, 12 years ago

milestone: 1.1

Milestone 1.1 deleted

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