Roy T. Fielding wrote: >> What would make more sense is "Error while reading HTTP request line. >> (remote browser didn't send a request?)". This indicates exactly what >> httpd was trying to do when the error occurred, and gives a hint of >> why the error might have occurred. > > We used to have such a message. It was removed from httpd because too > many users complained about the log file growing too fast, particularly > since that is the message which will be logged every time a browser > connects and then its initial request packet gets dropped by the network. > > This is not an error that the server admin can solve -- it is normal > life on the Internet. We really shouldn't be logging it except when > on DEBUG level.
As you say, it is normal life on the Internet. I don't think Apache should be hiding the fact that many browsers don't finish with the request line, or timeout in some other way. But the main problem, and it's how this all started, is that without the message it becomes very difficult to detect when you are being attacked. At the same time such attacks are trivial to execute and don't require a fast connection. A smart attacker will open new connections at a very slow rate, just a bit faster then Apache closes them. The only way to figure it out is to be there when it happens or use some other network-level mechanism (netflow, argus, etc), but even that would involve long time of looking at the logs and comparing it to the access logs. As for people complaining about the error log growing too fast, I am sure their access logs grow *much* faster and they handle that without a problem. My point being logging is part of the package. I am OK with assigning this message to a low log level, but I don't think DEBUG is the correct choice. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
