Feature Request: Emit `requestFinished` Event for Per-Request Bandwidth Tracking

[shresthaoshan]

Currently, the library emits a connectionClosed event, which is helpful for tracking the overall bandwidth usage of a socket connection. However, in many real-world scenarios involving persistent connections (e.g., HTTP keep-alive), it's valuable to monitor bandwidth usage on a per-request basis.

Feature Request

I’d like to propose adding support for a new event, requestFinished, which would be emitted at the end of each individual HTTP/HTTPS request-response cycle.

While precise per-request bandwidth usage may not be trivial to isolate due to socket reuse, this event would still provide:

• A time-based approximation of bandwidth usage across requests.
• Insight into request frequency, response size patterns, and endpoint behavior.
• A hook for logging, monitoring, or quota management per request.

Why This Matters

Tracking only at the socket level can obscure usage spikes or performance anomalies associated with individual requests—especially under connection pooling or when clients reuse a single proxy connection.

[tobice]

Thanks for the feature request! We're placing this into our backlog. We expect more capacity to be invested into proxy so there is a good chance we'll look into this soon.

[tobice]

Ah, sorry, I can see you have already sent a PR. We'll take a look 👍

[lewis-wow]

The PR was closed because of no activity, should I look into it?

[tobice]

I'd say go ahead. The no activity is probably on us 😄

[jancurn]

cc @bliuchak

[bliuchak]

We're having some diffulties with running tests. We're gonna take a look at it.

[lewis-wow]

Since the tests weren't working locally, we've set up a Docker environment for them. I can now run the tests and review the changes.