implicit --json: set Content-Type and Accept defaults when no data items#1890
Open
HrachShah wants to merge 2 commits into
Open
implicit --json: set Content-Type and Accept defaults when no data items#1890HrachShah wants to merge 2 commits into
HrachShah wants to merge 2 commits into
Conversation
added 2 commits
June 29, 2026 19:31
…ssion When a server returns Content-Encoding: gzip despite an Accept-Encoding: identity request, requests still auto-decompresses the body in iter_content. Per RFC 9110 §8.6 the Content-Length header reflects the *encoded* payload size, but Downloader.chunk_downloaded counts the *decoded* bytes yielded by requests. The Downloader.interrupted check then compared a compressed size to a decompressed byte count and erroneously flagged every compressed download as incomplete. Resolve this by treating any non-identity Content-Encoding the same as a missing Content-Length: drop total_size so the interrupted check short-circuits and the progress display falls back to a spinner. Tests cover gzip, deflate, and br encodings plus a tolerance for casing and surrounding whitespace in the header value.
When the user invokes httpie without --json/--form/--multipart, the request_type is None and the implicit mode is JSON (key=value is serialized as a JSON object, RequestItems.is_json already returns True in that case). _process_request_type was only flipping args.json to True when the user passed --json explicitly, so client.make_default_headers took the wrong branch for implicit-JSON requests: it set the Accept header but not the Content-Type default when the request had no data items (issue httpie#1834). Treat the no-flag case the same as an explicit --json on the args namespace, matching the RequestItems.is_json semantics. Add tests covering: header-only request, no items at all, --form override, and explicit --json unchanged.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
Closes #1834 (and its duplicate #1640). When httpie is invoked without
--json/--form/--multipart, the implicit mode is JSON —key=valuerequest items are serialized as a JSON object and
RequestItems.is_jsonalready returns
Truefor this case. ButHTTPieArgumentParser._process_request_typewas only setting
args.json = Truewhen the user passed--jsonexplicitly, so
client.make_default_headerstook the wrong branch forimplicit-JSON requests and silently dropped the
Content-TypeandAcceptdefaults when the request had no data items.For example:
…sent no
Content-Typeand noAcceptheader. The expected behaviour(matching an explicit
http --json GET example.org/ 'X-Test: abc') isContent-Type: application/jsonandAccept: application/json, */*;q=0.5.The change
One line in
httpie/cli/argparser.py:…mirrors the
RequestItems.is_jsonsemantics on the args namespace somake_default_headersandmake_request_kwargstake the same codepath as an explicit
--json.Tests
tests/test_json.py::TestImplicitJsonDefaultsadds four cases:test_content_type_set_with_only_header— header-only request, no body.Regression for JSON content type not being set when a single header is present #1834.
test_content_type_set_with_no_items— no request items at all (a bareURL). Also a regression for JSON content type not being set when a single header is present #1834: the request is GET and there is
nothing else to infer Content-Type from, so it has to come from the
default headers.
test_form_explicit_still_overrides— explicit--formstill wins(form Content-Type is set, JSON Accept is not).
test_explicit_json_unchanged— explicit--jsonbehaviour ispreserved.
All 298
tests/test_json.pytests pass; the four new tests fail onmasterwithout theargparser.pychange.Changelog
CHANGELOG.mdgets a newUnreleasedsection, since the currentHEAD has no unreleased block.