Opened 13 years ago

Closed 13 years ago

#1319 closed Bug (fixed)

DEFLATE compression issue

Reported by: spry Owned by: charles
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.34
Severity: Normal Keywords: deamon server deflate
Cc:

Description

Seems to me that new DEFLATE/ZLIB compression support has an issue. The data arrive corrupted, some deflate decompressors even refuse to decompress it, browsers decompress it wrong, like more that 60% of page contents is missing. I'm not fully sure about this bug, but without deflate support header from browser everything seems to be ok.

Change History (20)

comment:1 Changed 13 years ago by spry

All files, requested from webserver @ 9091 via deflate compression arrive incomplete

comment:2 Changed 13 years ago by charles

Judging from #1318, are you using build r6830 here?

comment:3 Changed 13 years ago by spry

Yeap

comment:4 Changed 13 years ago by charles

spry: could you see if r6845 makes matters any better or worse?

comment:5 Changed 13 years ago by spry

I do confirm that on HEAD revision

comment:6 Changed 13 years ago by charles

you confirm that it makes it better? or worse? or no change?

comment:7 Changed 13 years ago by spry

Well. Here is what transmission daemon says: deflated response from 4096 bytes to 1119 deflated response from 4096 bytes to 1490 deflated response from 4096 bytes to 1101 deflated response from 4096 bytes to 1095 deflated response from 4096 bytes to 1253 deflated response from 2587 bytes to 1056 deflated response from 845 bytes to 392 deflated response from 4096 bytes to 1670 deflated response from 1257 bytes to 606 deflated response from 4096 bytes to 1840 deflated response from 3704 bytes to 1356 deflated response from 4096 bytes to 1364 deflated response from 4096 bytes to 1365 deflated response from 4096 bytes to 1085 deflated response from 928 bytes to 939 deflated response from 1127 bytes to 1138 deflated response from 4096 bytes to 4072 deflated response from 4096 bytes to 4107 deflated response from 4096 bytes to 4107

And here is the end of unpacked response of /transmission/web

<div id="inspector_header">

<h1 id="torrent_inspector_name"></h1> <sp

And thats all. So it really makes no change. Some bytes more, but it does not matter really.

comment:8 Changed 13 years ago by spry

4096 bytes to 4107. That's kind of wierd, to compress 4096 bytes to 4107, but in any case that is possible

comment:9 Changed 13 years ago by spry

Can you test at your side using wget? like I've done 'wget http://127.0.0.1:9091/transmission/web/' and posted you tail of index.html that was downloader?

comment:10 Changed 13 years ago by charles

I've fixed that special case -- we now always use the smaller of the original form and the deflate()d form.

Odd how many responses are 4096 bytes...

comment:11 Changed 13 years ago by charles

Interesting:

#define EVBUFFER_MAX_READ 4096

comment:12 follow-up: Changed 13 years ago by charles

spry: are you using the libevent that's bundled in with Transmission, or one already installed on your OS? if the latter, which version number is it?

comment:13 Changed 13 years ago by spry

Transmission 6846: Request: GET text/html http://taburetka.co.ua:9091/transmission/web/ Result: 200, Content-Length 1119, Content-Encoding deflate

Content ends with:

<div id="inspector_header">

<h1 id="torrent_inspector_name"></h1> <sp

Firefox 3.0.2 with HttpFox?

Regarding libevent: I'm not forcing gmake to use some other libevent like from FreeBSD 7.0 p5, but I don't know how to test that.

comment:14 Changed 13 years ago by spry

Khm :) Stupid me :) Could you please erase my address? :) You can use that for testing, but for sure, stupid me to make that public

comment:15 in reply to: ↑ 12 Changed 13 years ago by mezz

Replying to charles:

spry: are you using the libevent that's bundled in with Transmission, or one already installed on your OS? if the latter, which version number is it?

I can reproduce spry's problem here on FreeBSD. It's more like spry is using libevent bundled, so for FreeBSD ports and mine too. I don't have any outside libevent install in my system. I get this:

% transmission
deflated response from 4096 bytes to 1119
deflated response from 4096 bytes to 1490
deflated response from 4096 bytes to 1101
deflated response from 4096 bytes to 1095
deflated response from 4096 bytes to 1253
deflated response from 2587 bytes to 1056
deflated response from 845 bytes to 392
deflated response from 4096 bytes to 1670
deflated response from 1257 bytes to 606
deflated response from 4096 bytes to 1840
deflated response from 3704 bytes to 1356
deflated response from 4096 bytes to 1364
deflated response from 4096 bytes to 1365
deflated response from 4096 bytes to 1085
deflated response from 4096 bytes to 4072
deflated response from 4096 bytes to 4107
deflated response from 4096 bytes to 4107

This output is from SVN r6845. I haven't tried r6846 yet, but I will in between tonight or Sunday whenever I can. spry will beat me. Tomorrow, I have to go to wedding and parties. No, I am not getting marry. It's just my cousin's wedding. ;-)

comment:16 Changed 13 years ago by mezz

Oh by the way, if I change from Z_DEFAULT_COMPRESSION to Z_NO_COMPRESSION or 0, I still get same result. So, must be "EVBUFFER_MAX_READ 4096" related or something else.

comment:17 Changed 13 years ago by spry

Seems to be that first log entry RPC Server: deflated response from 4096 bytes to 1119 And terminated transmission with size of 1255 bytes with Content Length of 1119 bytes have some connection. It was not fully transferred index.html. So, seems to be after new server has no more buffer space available for raw non compressed data (4K at the moment), it sends part of data and terminates data transfer. And also, end of 4096 bytes block of index.html exactly match the last bytes of real transfer, ends with "<h1 id="torrent_inspector_name"></h1> <sp ". So, it proves that incoming buffer for raw data in new server is only 4Kbytes or EVBUFFER_MAX_READ. And, or new server handles bigger files incorrectly, or this define should be increased to the maximum file size, or maximum response transfer size. I hope that there is some mistake in new server instead of dumb increasing a magic number.

comment:18 Changed 13 years ago by charles

  • Status changed from new to assigned

spry, mezz: could one of you test r6847 to see if that improves things?

comment:19 Changed 13 years ago by mezz

Tested r6847 and it works beautiful so far. Thanks! Althought, I haven't test to add/delete torrent but it shouldn't be make any difference for compression stuff.

comment:20 Changed 13 years ago by spry

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

Yeap, first five minutes it worked :) Now again I've met problems that no RPC responses arrive at all, but I thing that is not connected with this bug, so this bug is closed :)

Note: See TracTickets for help on using tickets.