httpx non-ASCII characters filename in multipart/form-data

The Fix

Upgrade to version 0.7.2 or later.

Based on closed encode/httpx issue #164 · 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%.

Jump to Verify Open PR/Commit

@@ -1,9 +1,17 @@
 import mimetypes
 import os
+import re
 import typing
 from io import BytesIO

repro.py

def render_headers(self) -> bytes:
-    name = quote(self.name, encoding="utf-8").encode("ascii")
-    filename = quote(self.filename, encoding="utf-8").encode("ascii")
-    content_type = self.content_type.encode("ascii")
     return b"".join(
         [
             b'Content-Disposition: form-data; name="',
-            name,
+            self.name.encode(),
             b'"; filename="',
-            filename,
+            self.filename.encode(),
             b'"\r\n',
             b"Content-Type: ",
-            content_type,
+            self.content_type.encode(),
             b"\r\n",
        ]
    )

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\nUpgrade to version 0.7.2 or later.\nWhen NOT to use: This fix should not be applied if strict ASCII compliance is required.\n\n

Why This Fix Works in Production

Trigger: Users experienced issues when uploading files with non-ASCII characters in their names.
Mechanism: httpx incorrectly escaped non-ASCII characters in multipart/form-data filenames
Why the fix works: Fixed the encoding of multipart header parameters to handle non-ASCII characters in filenames correctly. (first fixed release: 0.7.2).

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

httpx incorrectly escaped non-ASCII characters in multipart/form-data filenames
Production symptom (often without a traceback): Users experienced issues when uploading files with non-ASCII characters in their names.

Proof / Evidence

GitHub issue: #164
Fix PR: https://github.com/encode/httpx/pull/167
First fixed release: 0.7.2
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.58

Discussion

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

Jump to Sources Open on GitHub

“We should follow the HTML5 spec here for sure and not quote the characters. Are you comfortable making a PR to fix this behavior? Look…”

@sethmlarson · 2019-07-28 · source

Failure Signature (Search String)

Users experienced issues when uploading files with non-ASCII characters in their names.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
Users experienced issues when uploading files with non-ASCII characters in their names.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
Users experienced issues when uploading files with non-ASCII characters in their names.

Minimal Reproduction

repro.py

def render_headers(self) -> bytes:
-    name = quote(self.name, encoding="utf-8").encode("ascii")
-    filename = quote(self.filename, encoding="utf-8").encode("ascii")
-    content_type = self.content_type.encode("ascii")
     return b"".join(
         [
             b'Content-Disposition: form-data; name="',
-            name,
+            self.name.encode(),
             b'"; filename="',
-            filename,
+            self.filename.encode(),
             b'"\r\n',
             b"Content-Type: ",
-            content_type,
+            self.content_type.encode(),
             b"\r\n",
        ]
    )

What Broke

Users experienced issues when uploading files with non-ASCII characters in their names.

Why It Broke

httpx incorrectly escaped non-ASCII characters in multipart/form-data filenames

Fix Options (Details)

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

Upgrade to version 0.7.2 or later.

When NOT to use: This fix should not be applied if strict ASCII compliance is required.

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/167

First fixed release: 0.7.2

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

When NOT to Use This Fix

This fix should not be applied if strict ASCII compliance is required.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

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.7.2	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 non-ASCII characters filename in multipart/form-data (Fix)