Skip to content

implicit --json: set Content-Type and Accept defaults when no data items#1890

Open
HrachShah wants to merge 2 commits into
httpie:masterfrom
HrachShah:fix/request-type-default-is-json
Open

implicit --json: set Content-Type and Accept defaults when no data items#1890
HrachShah wants to merge 2 commits into
httpie:masterfrom
HrachShah:fix/request-type-default-is-json

Conversation

@HrachShah

Copy link
Copy Markdown

What this fixes

Closes #1834 (and its duplicate #1640). When httpie is invoked without
--json/--form/--multipart, the implicit mode is JSON — key=value
request items are serialized as a JSON object and RequestItems.is_json
already returns True for this case. But HTTPieArgumentParser._process_request_type
was only setting args.json = True when the user passed --json
explicitly, so client.make_default_headers took the wrong branch for
implicit-JSON requests and silently dropped the Content-Type and
Accept defaults when the request had no data items.

For example:

$ http GET example.org/ 'X-Test: abc'

…sent no Content-Type and no Accept header. The expected behaviour
(matching an explicit http --json GET example.org/ 'X-Test: abc') is
Content-Type: application/json and
Accept: application/json, */*;q=0.5.

The change

One line in httpie/cli/argparser.py:

-self.args.json = request_type is RequestType.JSON
+self.args.json = request_type is None or request_type is RequestType.JSON

…mirrors the RequestItems.is_json semantics on the args namespace so
make_default_headers and make_request_kwargs take the same code
path as an explicit --json.

Tests

tests/test_json.py::TestImplicitJsonDefaults adds four cases:

All 298 tests/test_json.py tests pass; the four new tests fail on
master without the argparser.py change.

Changelog

CHANGELOG.md gets a new Unreleased section, since the current
HEAD has no unreleased block.

Zo Bot 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.
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.

JSON content type not being set when a single header is present

1 participant