-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mod_http2 with mod_logio logs cumulative connection "bytes received" instead of per-request #158
Comments
The example above was demonstrated on a vanilla CentOS 7.4 system with Apache 2.4.33 compiled from source, using the default configuration except to enable mod_http2 and mod_logio:
|
The confusion stems from different connection re-use, I assume.
|
You are correct that it is related to connection re-use. There is at least an inconsistency in logging behavior of persistent connections. I have not been able to reproduce this behavior for the "Bytes out" counter when reusing HTTP/2 connections, only "Bytes in" appears to be affected. It also does not occur with HTTP/1.1 when using persistent connections. In all of these other cases, the per-request bytes are being logged. A per-connection "bytes in" counter is also not useful for log entries that are, in all other ways, per-request. A log analysis will not be able to determine the actual number of uploaded bytes for a range of requests if each %I field in the log is cumulative for a connection, because there is no connection identification available (like a unique "connection ID" field, for example). For example, how should the total number of bytes uploaded here be determined:
Is the total number of "bytes in" 629145600 or 314572800 for these three requests? The correct answer is 314572800 but it is impossible to know this without assuming information that is not available in the logs, which is the knowledge that these requests were made using the same connection. As far as I know, Apache has no method available to log the necessary information. Given only the information available, a log analysis must determine that the total number of "bytes in" is 629145600, which is not correct. |
You are correct. There is definitely something going very wrong here. The cumulative numbers are plain wrong. Working on it... |
mod_http2: accurate reporting of h2 data input/output per request via mod_logio. Fixes an issue where output sizes where counted n-times on reused slave connections. See gituhub issue: icing/mod_h2#158 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1828687 13f79535-47bb-0310-9956-ffa450edef68
Please check v1.10.17 for a fix. That one should report accurately the bytes in/out per request. |
I can confirm that this is resolved in v1.10.17.
Thank you! |
Fixed in v1.10.17. |
Instrument 'bbout' mod_http2: use proper ARP defined for formatting apr_off_t On the trunk: mod_http2: on level trace2, log any unsuccessful HTTP/2 direct connection upgrade with base64 encoding to unify its appearance in possible bug reports. On the trunk: * mod_http2: calculate unencrypted connection sniffing base64 only when log level is at required height. [Ruediger Pluem] On the trunk: mod_http2: accurate reporting of h2 data input/output per request via mod_logio. Fixes an issue where output sizes where counted n-times on reused slave connections. See gituhub issue: icing/mod_h2#158 Submitted by: jailletc36, icing, icing, icing, icing Reviewed by: icing, jim, ylavic git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1832489 13f79535-47bb-0310-9956-ffa450edef68
mod_http2: accurate reporting of h2 data input/output per request via mod_logio. Fixes an issue where output sizes where counted n-times on reused slave connections. See gituhub issue: icing/mod_h2#158 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1828687 13f79535-47bb-0310-9956-ffa450edef68
When using %I (mod_logio "Bytes received" field) or %S in LogFormat, the logged value is cumulative for the bytes received for the entire HTTP/2 connection and not per-request. This problem does not occur for %O (mod_logio "Bytes sent").
The simplest way that I have found to replicate this is with HTTP/2-enabled curl. It is not necessary for the upload to actually be "successful", as long as the request can be made to Apache. I get a 405 result in the example below because PUT is not implemented for the default configuration, but it is enough to show the issue with log output using the following:
Note that %S and %I are logging the cumulative received bytes, not just the received bytes for each request. The expected log output would be like when using HTTP/1.1:
The text was updated successfully, but these errors were encountered: