Opened 6 years ago

Closed 6 years ago

Last modified 4 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: UI/UX:

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 6 years ago.

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by sebastian_noack

comment:1 Changed 6 years ago by thatch

  • Component changed from Uncategorized to HTTP handling
  • milestone set to 1.1
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 follow-up: Changed 6 years ago by mtredinnick

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 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r10541.

comment:4 Changed 6 years ago by mtredinnick

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

Patch from sebastien_noack.

Backport of r10541 from trunk.

comment:5 in reply to: ↑ 2 Changed 6 years ago by sebastian_noack

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 Changed 6 years ago by mtredinnick

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 Changed 6 years ago by sebastian_noack

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 Changed 4 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

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