This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In rare cases, compression can result in data that is the same size, or even slightly larger.
If you want to test if the content is compressed, test that it is not the same as the uncompressed content.
Now, using connection_buf_add_compress, but detect_compression_method still returns NO_METHOD, and
tt_str_op(content, OP_NE, comp_body);
still fails.
So, it seems that even if find_best_compression_method returns ZLIB and the header has Content-Encoding: deflate, the data is not compressed and it's the same.
I'm not sure if i'd need to try with a bigger string.
So one easy way to debug this would be to fetch and log the entire contents of "TO_CONN(conn)->outbuf" right before the fetch_from_buf_http. That way you'll be able to see whether it's compressing or not, and localize the failure there.
Incidentally, strlen(content)+1 is not a great upper bound for the compressed body length, since it could be larger than the original content.
Also, the compressed body, if it's really compressed, is going to be a sequence of bytes with some 0 bytes, so you can't rely on it being nul-terminated, so you can't use strcmp() or tt_str_op() on it.
If it turns out that the data isnt' being compressed, one way to debug that would be to log the chosen compression_method from inside directory_handle_command_get.
This code sets the compression state on the connection, then adds the data uncompressed.
Here's some similar code that correctly adds the data compressed:
tor/src/feature/dircache/dircache.c
Lines 1034 to 1048 in 8020d6f
tor/src/feature/dircache/dircache.c
Lines 1292 to 1310 in 8020d6f
It's not great to copy code, but I opened a ticket to clean up:
https://trac.torproject.org/projects/tor/ticket/28815