#2449 closed defect (fixed)
[patch] GZipMiddleware shouldn't gzip JavaScript
| Reported by: | James Bennett | Owned by: | Adrian Holovaty |
|---|---|---|---|
| Component: | Core (Other) | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Internet Explorer is known to have issues with gzipped JavaScript content, and in some testing of various AJAXy things I also found some weird issues with JSON responses being mangled only when GZipMiddleware was enabled.
So it'd probably be a good idea for the middleware to look at the outgoing Content-Type and not compress if it's JavaScript.
Attachments (2)
Change History (7)
by , 18 years ago
comment:1 by , 18 years ago
| Summary: | GZipMiddleware shouldn't gzip JavaScript → [patch] GZipMiddleware shouldn't gzip JavaScript |
|---|
comment:2 by , 18 years ago
It looks like this patch won't handle the case where the Content-Type header includes a charset:
Content-Type: text/javascript; charset=utf-8
There are routines in the Python email package that can handle parsing this kind of information out of a header, although to be honest the following would probably work fine:
'javascript' in response.headers['Content-Type']
comment:4 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Patch to make GZipMiddleware smarter about JavaScript