Uncompressed, non-DEFLATE response broken

[spry]

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

[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.

[spry]

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

[charles]

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.

[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

[spry]

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

[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

[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; 
 } 

[spry]

Proper fix

[spry]

I've added proper fix against r6866

[charles]

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

[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)

[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)

[spry]

Link: ​http://download.taburetka.co.ua/downloads1/transmission-daemon.core 14 megabytes

[spry]

Or ​http://download.taburetka.co.ua/downloads1/transmission-daemon.core.tar.gz 5megs

[spry]

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

[spry]

​http://***/transmission/web/index.html works ​http://***/transmission/web/ gives Error 404

[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.

[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..

[charles]

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

[charles]

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.

[charles]

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