Logging all wire communication (request & response)

[HiranChaudhuri]

Hello there.
I came here through an application that makes use of this library. It is used to call webhooks, and the application allows them to be configured via UI. However, every now and then users have problems getting the configuration right. When troubleshooting it helps a lot if users are able to see both the http request and response - I mean all the bytes or characters that are transmitted.

I checked #3073 but that seems to focus on logging response bodies.
Now the question: How can httpx be used such that all transmitted bytes are getting logged?

[Chenghao999]

event_hooks is what you want — both hooks receive the live objects, so you can log exactly the bytes that went out and came back:

import httpx

def log_request(request: httpx.Request) -> None:
    print("-->", request.method, request.url)
    print("    headers:", request.headers)
    print("    body:", request.content)

def log_response(response: httpx.Response) -> None:
    response.read()                      # required — see below
    print("<--", response.status_code, response.url)
    print("    headers:", response.headers)
    print("    body:", response.content)
    return response

client = httpx.Client(event_hooks={
    "request": [log_request],
    "response": [log_response],
})

response.read() is not optional. The response hook runs before the body has been read, so response.content raises ResponseNotRead. I checked that against a real request on 0.28.1, not only a mock. Calling read() inside the hook loads it — the trade-off being you've given up the memory benefit of streaming, fine for a troubleshooting logger you switch on but not something to leave enabled by default; gate it on a flag or env var when you construct the client.

Two things this surfaces nicely for your webhook case:

• The request hook sees what httpx actually sends, including headers it added itself (Host, Accept-Encoding, User-Agent, Content-Length). "It sent content-type: application/json and the user expected form-encoded" is exactly the class of mistake this catches.
• On the response side you get status and headers even when the body is what's confusing.

One limit worth stating: this logs the HTTP-level request/response, not the TLS wire bytes. For the actual encrypted stream you need a proxy (mitmproxy, Charles) — httpx can't show you that.

[Doribelove]

One correction to the hook-based answer above: event hooks can log the HTTPX request/response objects, but they are not an exact wire-byte recorder.

I checked this with HTTPX 0.28.1 using a streaming request and a streamed gzip response in MockTransport:

• In the request hook, request.content raised RequestNotRead for a body supplied as an iterator. Reading it in the hook would buffer the stream before the transport sends it.
• In the response hook, response.content raised ResponseNotRead until response.read() was called. That call returned the decoded payload (b"hello"), not the gzip-compressed response bytes.

So, for troubleshooting webhook configuration, hooks are useful for method, URL, headers, and application-level bodies if you intentionally buffer them. Redact authorization/cookie values before sharing such logs. If you need the actual HTTP exchange bytes, including content encoding/framing, use an intercepting proxy or a capture at the transport/network layer; HTTPX's event hooks and httpcore logging do not promise a byte-for-byte transcript. httpcore trace events describe network operations but are not a full body dump either.

AI assistance was used to prepare this reply; I ran the local HTTPX reproduction and checked the official documentation.