You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2009/11/30 12:08:52 UTC
DO NOT REPLY [Bug 48301] New: Feature request: improved connection
status reporting
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
Summary: Feature request: improved connection status reporting
Product: Apache httpd-2
Version: 2.2.14
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: mod_log_config
AssignedTo: bugs@httpd.apache.org
ReportedBy: ajp.sheppard@gmail.com
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 48301] Feature request: improved connection status
reporting
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
Dan Poirier <po...@pobox.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #3 from Dan Poirier <po...@pobox.com> 2010-05-03 14:36:52 EDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 48301] Feature request: improved connection status
reporting
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
--- Comment #1 from Mark Thomas <ma...@apache.org> 2009-11-30 16:48:28 GMT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 48301] Feature request: improved connection status
reporting
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
--- Comment #4 from alanj <aj...@gmail.com> 2010-05-04 11:55:10 EDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 48301] Feature request: improved connection status
reporting
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
alanj <aj...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 48301] Feature request: improved connection status
reporting
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48301
--- Comment #2 from alanj <aj...@gmail.com> 2009-12-03 06:10:06 UTC ---
(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?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org