Emscripten/Pyodide fetch transport crashes on responses with a null body (e.g. 204 No Content)

[qte77]

Bug

JavascriptFetchTransport.handle_request / AsyncJavascriptFetchTransport.handle_async_request (httpx/_transports/jsfetch.py, present in the 0.28.1 tag and master) both route through _js_response_to_python (around line 171-188), which unconditionally does:

body_stream_js = response_js.body.getReader()

Any response whose JS-side body is null -- a 204 No Content is the clearest real-world case, but this would apply to any response the browser/runtime's fetch layer represents with a null body -- crashes with:

AttributeError: 'JsNull' object has no attribute 'getReader'

instead of returning a valid httpx.Response with an empty body.

Environment

• Emscripten/Pyodide runtime (confirmed against hoodmane/httpx tag pyodide_release_5, which carries the identical unguarded line -- filing here since that fork and this repo both have Issues disabled, and this looked like the closest fit among the Discussion categories).
• Any HTTP call (sync or async) against an endpoint that legitimately returns a 204, or otherwise a null-body response -- standard, spec-compliant HTTP behavior for many REST APIs (e.g. a successful PUT with no representation to return).

Expected

_js_response_to_python returns an httpx.Response with an empty body (e.g. httpx.Response(status_code, headers=..., stream=httpx.ByteStream(b""))) when the underlying JS response has no readable body stream, instead of assuming .body is always stream-shaped.

Suggested fix

Guard the body-stream access, e.g. duck-type on hasattr(body, "getReader") (safer than a JsNull type check, which is more version-fragile) before calling .getReader(), and construct an empty-body response on the fallback path. Both the sync and async call sites resolve _js_response_to_python via a bare module-global lookup, so a single fix at that function covers both.

Happy to provide a minimal repro script if useful -- this was found via a real production workload hitting a real 204 response, not synthetically constructed.

[ryux1]

I verified this against both repositories. encode/httpx 0.28.1 and current master do not contain httpx/_transports/jsfetch.py; the transport lives on hoodmane/httpx:pyodide.

The null-body diagnosis is correct there. I submitted a focused fix to the branch that actually ships the transport, with sync and async browser regressions against a real 204 response:

hoodmane#2

The shared adapter now falls back to ByteStream(b"") when the JS body has no getReader, so both fetch transports return a valid empty HTTPX response.