httpx Any explicit `Content-Type` header should take

The Fix

Upgrade to version 0.13.0 or later.

Based on closed encode/httpx issue #620 · PR/commit linked

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Open PR/Commit

@@ -624,7 +624,7 @@ def __init__(
             self.content = content
             if content_type:
-                self.headers["Content-Type"] = content_type
+                self.headers.setdefault("Content-Type", content_type)
         elif isinstance(data, (str, bytes)):

fix.md

Option A — Upgrade to fixed release\nUpgrade to version 0.13.0 or later.\nWhen NOT to use: This fix should not be used if the application relies on the default Content-Type behavior for JSON requests.\n\n

Why This Fix Works in Production

Trigger: We shouold probably change this...
Mechanism: The Content-Type header was being replaced by the default 'application/json' when a user-defined Content-Type was provided
Why the fix works: Allows explicit Content-Type headers to take precedence over encoding Content-Type headers, addressing the issue where user-defined Content-Type was being replaced by 'application/json'. (first fixed release: 0.13.0).

Production impact:

If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.

Why This Breaks in Prod

The Content-Type header was being replaced by the default 'application/json' when a user-defined Content-Type was provided
Production symptom (often without a traceback): We shouold probably change this...

Proof / Evidence

GitHub issue: #620
Fix PR: https://github.com/encode/httpx/pull/633
First fixed release: 0.13.0
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.81

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“Sure thing”

@lovelydinosaur · 2019-12-09 · source

“Hi @daxartio, What exact use case are you facing that requires passing json=... while setting a Content-Type to something else than application/json? As a workaround,…”

@florimondmanca · 2019-12-09 · source

Failure Signature (Search String)

We shouold probably change this...

Copy-friendly signature

signature.txt

Failure Signature
-----------------
We shouold probably change this...

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
We shouold probably change this...

What Broke

Requests with explicit Content-Type headers were incorrectly defaulting to 'application/json', causing unexpected behavior.

Why It Broke

The Content-Type header was being replaced by the default 'application/json' when a user-defined Content-Type was provided

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

Upgrade to version 0.13.0 or later.

When NOT to use: This fix should not be used if the application relies on the default Content-Type behavior for JSON requests.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Fix reference: https://github.com/encode/httpx/pull/633

First fixed release: 0.13.0

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix should not be used if the application relies on the default Content-Type behavior for JSON requests.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
Upgrade behind a canary and run integration tests against the canary before 100% rollout.

Version Compatibility Table

Version	Status
0.13.0	Fixed

Related Issues

No related fixes found.

Cluster: httpx:configuration-error All hubs All clusters

Related clusters: Data consistency Other Timeout

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

httpx Any explicit `Content-Type` header should take precedence over the encoding default. (Fix)