You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2004/10/25 10:37:23 UTC
Re: cvs commit: httpd-2.0/server protocol.c
pquerna@apache.org wrote:
> server protocol.c
> Log:
> This will put some messages in the error log when some people try a lame
> DoS by just opening a socket, and never sending any data.
> + else if (r->connection->keepalive != AP_CONN_KEEPALIVE) {
> + ap_log_rerror(APLOG_MARK, APLOG_NOTICE, rv, r,
> + "request line read error.");
> + }
Is it possible to put a more descriptive message than "request line read
error". If I was to see that in a logfile, I would have absolutely no
idea whatsoever what it was trying to tell me :(
Regards,
Graham
--
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Paul Querna <ch...@force-elite.com>.
Graham Leggett wrote:
> Rici Lake wrote:
>
>> I believe that ap_log_rerror() inserts the OS error description,
>> resulting in something like:
>>
>> [client 127.0.0.1] (70007)The timeout specified has expired: request
>> line read error
>>
>> Of course, this is OS dependent.
>
>
> That still means little to me as an end user, as I would think a
> "request line read error" was some OS error that I needed to be
> concerned about, leading me on a wild goose chase.
>
> 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.
Well.. Apache isn't just an HTTP server right?
Now Committed:
"Error while reading request line. (client didn't send a request?)"
I also changed it to a INFO. I forgot how much NOTICE sucked.
Thanks for the comments.
-Paul
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Rici Lake <ri...@ricilake.net>.
On 25-Oct-04, at 11:04 PM, Roy T. Fielding wrote:
> 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.
That was my first reaction, too. However, Ivan Ristic pointed out that
(in some cases, anyway) it is the result of a DoS attack, and there may
be something a server admin can do about it. Or, if not, at least they
might know why their server is suddenly performing badly.
For example, we had a problem report on #apache a couple of days ago
which turned out, after considerable investigation, to be the result
of a single host ip issuing hundreds of request connections in a few
minutes. Whether this was a deliberate attack or simply a buggy
client is not clear (to me) but the temporary solution of blocking
the ip address was certainly within the server admin's abilities.
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Ivan Ristic <iv...@webkreator.com>.
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 ]
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, October 25, 2004 9:04 PM -0700 "Roy T. Fielding"
<fi...@gbiv.com> wrote:
> 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.
+1. Info loglevel is way way too high for realistic sites. -- justin
Re: cvs commit: httpd-2.0/server protocol.c
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> 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.
....Roy
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Rici Lake <ri...@ricilake.net>.
On 25-Oct-04, at 9:57 AM, Graham Leggett 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.
That works for me, although I would drop the word "remote". Perhaps
"(Browser didn't send a complete request)" would be more accurate, but
that is maybe overly-pedantic.
R.
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Graham Leggett <mi...@sharp.fm>.
Rici Lake wrote:
> I believe that ap_log_rerror() inserts the OS error description,
> resulting in something like:
>
> [client 127.0.0.1] (70007)The timeout specified has expired: request
> line read error
>
> Of course, this is OS dependent.
That still means little to me as an end user, as I would think a
"request line read error" was some OS error that I needed to be
concerned about, leading me on a wild goose chase.
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.
The clearer the error message, the less chance of an admin wasting time
fiddling in the dark trying to understand what it all means.
Regards,
Graham
--
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Rici Lake <ri...@ricilake.net>.
On 25-Oct-04, at 3:37 AM, Graham Leggett wrote:
>
>> + else if (r->connection->keepalive !=
>> AP_CONN_KEEPALIVE) {
>> + ap_log_rerror(APLOG_MARK, APLOG_NOTICE, rv, r,
>> + "request line read error.");
>> + }
>
> Is it possible to put a more descriptive message than "request line
> read error". If I was to see that in a logfile, I would have
> absolutely no idea whatsoever what it was trying to tell me :(
I believe that ap_log_rerror() inserts the OS error description,
resulting in something like:
[client 127.0.0.1] (70007)The timeout specified has expired: request
line read error
Of course, this is OS dependent.