Skip to content

Fixes #1972: Add tests for automatic request compression with single --compress flag - #1991

Open
vinayK34 wants to merge 1 commit into
httpie:masterfrom
vinayK34:fix/1972-compression-tests
Open

vinayK34 wants to merge 1 commit into
httpie:masterfrom
vinayK34:fix/1972-compression-tests

Conversation

@vinayK34

Copy link
Copy Markdown

This adds end-to-end JSON and raw-body cases over both HTTP and HTTPS. They check that the server receives Content-Encoding: deflate, that decompression restores the original payload, and that Content-Length equals the compressed byte count.

The tests cover the normal case where one --compress flag compresses a body because the result is smaller, which was missing from the existing compression suite.

  • Added test_compress_json_normal() for JSON body compression with single flag
  • Added test_compress_raw_normal() for raw body compression with single flag

These tests verify that when using one --compress flag, the body gets compressed only when the compressed version is smaller than the original.

…ingle --compress flag

This adds end-to-end JSON and raw-body cases with a single --compress flag,
which tests the normal case where compression occurs because the result is smaller.
@vinayK34
vinayK34 marked this pull request as ready for review October 28, 2026 06:38
Comment thread tests/test_compress.py
'foo=bar',
)
assert HTTP_OK in r
assert r.json['headers']['Content-Encoding'] == 'deflate'

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this new test conflicts with test_compress_skip_negative_ratio() earlier in the same file.

Both tests send the same small JSON payload (foo=bar) with a single --compress flag.

The existing test correctly expects no Content-Encoding header because compressing such a small payload increases its size. This new test expects deflate for the identical request, so the two assertions cannot both pass.

Could we use a larger, repetitive JSON payload here to make compression beneficial?

That would let this test cover the intended positive-compression case while preserving the existing negative-ratio behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants