Custom Query (2447 matches)

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

after setting web base in web.conf i get this error when trying to access webui:

web.Server Traceback (most recent call last):
builtins.TypeError: must be str, not bytes
/usr/lib/python3/dist-packages/twisted/web/server.py:190 in process
189        try:
190            resrc = self.site.getResourceFor(self)
191            if resource._IEncodingResource.providedBy(resrc):
/usr/lib/python3/dist-packages/twisted/web/server.py:826 in getResourceFor
825        request.sitepath = copy.copy(request.prepath)
826        return resource.getChildForRequest(self.resource, request)
827
/usr/lib/python3/dist-packages/twisted/web/resource.py:98 in getChildForRequest
97        request.prepath.append(pathElement)
98        resource = resource.getChildWithDefault(pathElement, request)
99    return resource
/usr/lib/python3/dist-packages/deluge/ui/web/server.py:561 in getChildWithDefault
560        if base[0] != '/':
561            base = '/' + base
562web.Server Traceback (most recent call last):
builtins.TypeError: must be str, not bytes
/usr/lib/python3/dist-packages/twisted/web/server.py:190 in process
189        try:
190            resrc = self.site.getResourceFor(self)
191            if resource._IEncodingResource.providedBy(resrc):
/usr/lib/python3/dist-packages/twisted/web/server.py:826 in getResourceFor
825        request.sitepath = copy.copy(request.prepath)
826        return resource.getChildForRequest(self.resource, request)
827
/usr/lib/python3/dist-packages/twisted/web/resource.py:98 in getChildForRequest
97        request.prepath.append(pathElement)
98        resource = resource.getChildWithDefault(pathElement, request)
99    return resource
/usr/lib/python3/dist-packages/deluge/ui/web/server.py:561 in getChildWithDefault
560        if base[0] != '/':
561            base = '/' + base
562
builtins.TypeError: must be str, not bytes
builtins.TypeError: must be str, not bytes

Built deluge from develop on archlinux. Install and start the daemon with systemctl. Start deluge-console. The local daemon is not shown as contactable.

The log shows:

14:47:38.112 [WARNING ][deluge.transfer :136 ] Failed to decompress (25 bytes) and load serialized data with rencode: loads() got an unexpected keyword argument 'decode_utf8'

Running 'python2', importing rencode and calling loads() manually it does accept the 'decode_utf8' keyword.

If I use inspect in transfer.py to show in the log the function signature for loads() it says: ArgSpec(args=x, varargs=None, keywords=None, defaults=None) which does not match the behavior in the interactive session ie no 'decode_utf8' keyword param.

There is a bug against rencode on github which appears to be the same issue: ​https://github.com/aresch/rencode/issues/15

I note that the call to rencode.dumps() in transfer_message() in transfer.py does not do any utf8 encoding, so I tried just removing the 'decode_utf8=True' arg, but I get: 9:29:29.127 [INFO ][deluge.core.rpcserver :171 ] Deluge Client connection made from: 127.0.0.1:54980 19:29:29.155 [INFO ][deluge.core.rpcserver :197 ] Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost.

I may be unable to access the internet in the next week (China!). Apologies for any delay in responding to updates on this.