Deluge
Custom Query (2448 matches)
Results (166 - 168 of 2448)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1363 | WontFix | Detect previously used settings in installer when upgrading | tobbez | |
| Description |
It would be nice if previously used settings (magnet link and torrent file association, GTK installation) were detected in the installer when upgrading, and their checkboxes automatically (un)checked. |
|||
| #2338 | Fixed | typo in web UI (back-end) error message | damoxc | tmetro |
| Description |
When adding a torrent from a URL that fails to download, the web UI back-end logs: [ERROR ] 16:56:57 json_api:661 Error occured downloading torrent from https://btguard.com/broken-test.torrent "occured" is spelled wrong. (I'm guessing this is in deluge/ui/web/json_api.py.) |
|||
| #3244 | Fixed | Use gzip content encoding only if supported by client | tkSimon | |
| Description |
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 |
|||
