Skip to content

accumulate the total bytes received from client requests using r->request_length - #1998

Open
finditfun wants to merge 3 commits into
alibaba:masterfrom
finditfun:master
Open

accumulate the total bytes received from client requests using r->request_length#1998
finditfun wants to merge 3 commits into
alibaba:masterfrom
finditfun:master

Conversation

@finditfun

Copy link
Copy Markdown

The $request_length variable records only the size of the request line and headers during the CONNECT method in this module, and does not include the TLS handshake or request body bytes transmitted after the tunnel is established.

In the code, the subsequent bytes read from the client are added to r->request_length, allowing observation of the total packet size sent by clients in forward proxy requests via the $request_length field in logs.

…uest_length

The $request_length variable records only the size of the request line and headers during the CONNECT method in this module, and does not include the TLS handshake or request body bytes transmitted after the tunnel is established. 

In the code, the subsequent bytes read from the client are added to r->request_length, allowing observation of the total packet size sent by clients in forward proxy requests via the $request_length field in logs.
@drawing

drawing commented Mar 24, 2026

Copy link
Copy Markdown
Collaborator

Thank you for this contribution! I've reviewed the changes and have some concerns regarding the semantic consistency of r->request_length.

Concern: Semantic mismatch

In Nginx/Tengine, `` is officially defined as:

The length of the request (including request line, headers, and body)

This variable is meant to track HTTP-layer request size. However, in CONNECT tunnel mode, the subsequent data transferred through the tunnel is raw TCP traffic (typically encrypted TLS streams), not HTTP requests. Adding these bytes to r->request_length breaks the semantic contract of this variable and may mislead users who rely on it for HTTP request analysis.

Additional issue: Incomplete statistics

The condition !from_upstream && !do_write only triggers on the first read from the client. Since CONNECT tunnels involve continuous bidirectional communication, this approach only captures the first chunk of data and doesn't reflect the actual tunnel traffic.

Suggested alternative

If you need to track CONNECT tunnel traffic, I recommend:

  1. Introducing dedicated variables in the proxy_connect module (e.g., /)
  2. Or leveraging existing variables like `` with custom log formats to distinguish proxy tunnel scenarios

This would preserve the semantic integrity of `` while providing accurate tunnel traffic metrics.

Would you be open to revising the implementation along these lines?

Added variables to track bytes sent and received in the proxy connect module. Implemented a new variable function to retrieve these values.
@finditfun

Copy link
Copy Markdown
Author

@drawing Added variables to track bytes sent and received in the proxy connect module. Implemented a new variable function to retrieve these values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants