Opened 12 years ago

Closed 12 years ago

#1330 closed Bug (fixed)

Uncompressed, non-DEFLATE response broken

Reported by: spry Owned by: charles
Priority: Normal Milestone: 1.40
Component: libtransmission Version: 1.34
Severity: Normal Keywords: rpc server compression
Cc:

Description

If browser sends that it does not support DEFLATE compression method, Transmission server responses with no data included. Rev 6865

Attachments (3)

r6865-unsupported_deflate.diff (2.7 KB) - added by spry 12 years ago.
Fix against r6865 that returns support of raw data responses if client app can not handle DEFLATE compression . Also this fixed bug with images and etc in web interface due to a logic bug. See below
r6866-deflate_and_raw_fix.diff (2.8 KB) - added by spry 12 years ago.
Proper fix
json.c.diff (785 bytes) - added by charles 12 years ago.
debug messages to help track down the json.c assert error

Download all attachments as: .zip

Change History (22)

comment:1 Changed 12 years ago by spry

Also, regarding DEFLATE compression itself, for some reason, unknown to me, not all decompressors that support DEFLATE, can unpack the stream from server. Browsers are able, deflate unpacker that is capable of 1.3 DEFLATE version, fails. I do wonder why, but still can not figure out why.

comment:2 Changed 12 years ago by spry

Well. .NET Class System.IO.Compression.DeflateStream? can not handle decompression of DEFLATED stream from Transmission server :(

comment:3 Changed 12 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 1.40
  • Owner set to charles
  • Status changed from new to assigned

the topic of this ticket is fixed now in r6866. thanks spry!

please don't load two issues into the same ticket; it makes the tickets harder to manage.

If you think that System.IO.Compression.DeflateStream?'s failure is caused by something Transmission is doing wrong, please open a new ticket for that issue.

comment:4 Changed 12 years ago by charles

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

Changed 12 years ago by spry

Fix against r6865 that returns support of raw data responses if client app can not handle DEFLATE compression . Also this fixed bug with images and etc in web interface due to a logic bug. See below

comment:5 Changed 12 years ago by spry

  • Resolution fixed deleted
  • Status changed from closed to reopened

Old code wrote directly to output buffer and if there was some error, just stopped adding DEFLATEd data and added full amount of raw data. New code firstly makes sure that DEFLATEd data is OK and its size is less that raw data and only then writes to buffer or deflated or raw data

comment:6 Changed 12 years ago by spry

charles: Sorry that first time I've added only first half of solution :) Few seconds later I've realized that there is another bug there

comment:7 Changed 12 years ago by spry

Damn.. fixed 2 bugs, added 1 own. There is a memleak. Can you add 1 line more?

 { 
 	deflateEnd( &stream ); 

free(pCompressedData);  << missing

 	return err; 
 } 

Changed 12 years ago by spry

Proper fix

comment:8 Changed 12 years ago by spry

  • Status changed from reopened to new

I've added proper fix against r6866

comment:9 Changed 12 years ago by charles

I think I've fixed this in r6867 + r6868 but avoid the extra malloc. Could you test this to confirm/refute the fix?

comment:10 Changed 12 years ago by spry

Web interface in r6868 is giving error 404 Not Found. My remote control shows that RPCs work ok, both with DEFLATE and RAW, but I'm unable to test the bug that appeared in web interface that caused a pack of DEFLATE(not full)+RAW to be transmitted if sizeof(DEFLATE) >= sizeof(RAW)

comment:11 Changed 12 years ago by spry

Also found an old bug, that I was telling about at very beginning

RPC Server: Deflated response from 427 bytes to 192
RPC Server: Deflated response from 668709 bytes to 42974
Assertion failed: (!data->key), function callback, file json.c, line 122.
Abort trap: 6 (core dumped)

comment:14 Changed 12 years ago by spry

Well, I have not seen this on r6866 + my diffs. But maybe that is not directly connected

comment:16 Changed 12 years ago by charles

yeah, I just noticed that /transmission/web/ bug too.

It's crazy how many times rpc-server's had to be re-tweaked. Thanks for helping out on the testing.

comment:17 Changed 12 years ago by spry

:) Always glad to help. Have you looked at the core dump? That bug is driving me crazy. Only my remote control somehow is doing somewhat that crashes transmission via RPC.. And this bug I've seen @ 1.32, 1.33, releases, and now on r6868, on r6866 and prior everything was O.k. The strangest thing that I hadn't made any changes to my code, and seems no major changes was done to JSON/RPC system, except for HTTP response encoding..

comment:18 Changed 12 years ago by charles

that corefile isn't going to do me any good. It would be better to attach a valgrind log, if possible.

comment:19 Changed 12 years ago by charles

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

actually, even better than either of those, apply this patch that adds some debugging messages, and if/when you get another crash from that assertion, attach the text of that session here.

although, since this is actually a different issue than the deflate issue, please open another ticket for this... especially since this crash fix would be a backport-candidate in case there's a 1.35 release.

marking the deflate issue as fixed.

Changed 12 years ago by charles

debug messages to help track down the json.c assert error

Note: See TracTickets for help on using tickets.