Currently the LogFormat and CustomLog directives support the "%X" format string which indicates the connection status when response is completed. This format string is extremely useful for determining how the end user accessing a site is served, especially for requests that have a potential to fail - such as long running request/response that generate a large amount of content (e.g. downloading a large file). The problem is that the %X directive does not provide enough granulatity to indicate whether the connection was aborted by the client side or by the server (Apache) side. This is a very important metric as web analysts need to be able to distinguish if the failure of an end user to receive a response is due to an issue on the Apache side (e.g. due a possible configuration issue such as a low TimeOut value) or due to the client aborting or canceling. An initial examination of the code indicates that it is possible to clearly distinguish these two cases. I suggest the following modification to connection status when the response completes: X = connection aborted by the SERVER before the response completed. x = connection aborted by CLIENT side the before the response completed.
Note that due to a data loss on 26/27 Nov 2009 the issue that was originally created as bug 48301 was lost. It has been re-created as bug 48312.
(In reply to comment #1) > Note that due to a data loss on 26/27 Nov 2009 the issue that was originally > created as bug 48301 was lost. It has been re-created as bug 48312. The above comment does not appear to be correct. bug 48312 is a completely different bug. Can you clarify the status of bug 48301?
Could you expand on what sort of cases you're thinking of where the server aborts the connection? There are a very few cases where some error occurs in the server and it aborts the connection, but in almost all cases, the Apache web server aborts the connection because it's detected an error on the connection, which is the network or the client's fault, not the server's. Arguably if the client stops responding and some timeout expires, that's also the client's fault, not the server's. So I think we'd be logging "client abort" 99.9% of the time, which doesn't sound all that useful.
Let me expand on the sort of cases where the server aborts the connection. I will outline both the technical details and the business requirements to give the issue some overall context. A lot of companies now use the web to allow end users to download software and this typically results in the end user's browser initiating a GET request which results in a response containing the software. For a company this means their web site and back end web server is of extreme importance in serving their user community. The HTTP response containing the software download may take a long time to complete depending on the size of the download, the network latency and bandwidth between the client and server. If the connection is terminated, "X" appears in the access log but it's not possible to know if the client terminated the connection or the server terminated it. If the client terminated the connection, well that's OK - it's a user initiated decision, however if the server terminated it then it can indicate an underlying problem with the Apache configuration or supporting infrastructure which should be addressed. So it's very important to know whether it's client or server initiated. Some scenarios in which the server can terminate the connection are as follows: (1) the client is on a high latency, low bandwidth connection (such as a modem) and during the download it experiences periodic intervals in which no TCP ACK is sent due to congestion as it attempts to empty its local receive buffer. If the Apache Timeout directive is set too low in this situation then the Server terminates the connection. (2) when multiple clients are downloading simultaneously it's possible that they may cause the bandwidth allocation of the web servers to reach capacity. In this situation the Server terminates the connection as it cant receive a TCP ACK due to congestion. In the first scenario a change to the Apache config is required, in the second an infrastructure upgrade may be required, but the important aspect is that the network termination is due to an issue within the server domain and is not user initiated. It may be true that in a lot of instances this type of abort does not appear often but it also true that when it occurs it should be easily detected and the desired metrics should be available to facilitate this.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.