Opened 6 years ago

Closed 6 years ago

#3244 closed bug (Fixed)

Use gzip content encoding only if supported by client

Reported by: tkSimon Owned by:
Priority: minor Milestone: 2.x
Component: Web UI Version: other (please specify)
Keywords: Cc:

Description (last modified by Calum)

At the moment deluge responds to requests for certain resource with gzip content encoding regardless of the requests accept-encoding header. It should only use gzip encoding if supported by the client.

Personally, I wanted deluge to respond with uncompressed assets because i have an nginx reverse proxy in front of deluge that's doing brotli (and gzip compression,) and caching those. The issue being that nginx only compresses when the origin (deluge) sends them uncompressed. This is usually achieved by configuring nginx to not forward the accept-encoding header.

To reproduce, run: curl 127.0.0.1:8112/js/ext-extensions.js -o /dev/null -v

The response will have a "Content-Encoding: gzip" header, and it's payload will be gzipped even though the request doesn't contain an "Accpet-Encoding: gzip" header.

I created a PR to fix this: https://github.com/deluge-torrent/deluge/pull/232

Change History (3)

comment:1 by Calum, 6 years ago

Component: UnknownWeb UI
Description: modified (diff)
Milestone: needs verified2.x

Based on your use-case I agree that this would be good to fix.

Using the Twisted resource wrapper is a better way to do this and I have created a PR: https://github.com/deluge-torrent/deluge/pull/233

We should also only compress text and not images and that can be included in the changes.

comment:2 by Calum, 6 years ago

Fixed in develop: [db021b9f415]

comment:3 by Calum, 6 years ago

Resolution: Fixed
Status: newclosed
Note: See TracTickets for help on using tickets.