Re: [patch] TUX 2.4.2-P3

[Ingo Molnar <mingo elte hu>]

On Sun, 11 Mar 2001, Marcus Gruendler wrote:

> Hi, it's me again.
>
> I'm sorry to say, but there is some strange behaviour in this patch.
> When I boot my system, start tux and do a static request whith
> netscape e.g. to http://myhost/index.html I receive the page whithout
> problems. Then 30 seconds later the system log tells me that there was
> a connection timeout:
>
> ... <154824:accept.c:276>: req c7a2e800 timed out after 30 sec

i suspect Netscape kept a HTTP/1.1 keepalive connection around - just in
case you enter another request. If this is the case then this is a valid
optimization - Netscape keeps the TCP connection open, so it doesnt have
to build it again for the next request.

TUX has a default keepalive timeout of 30 seconds - this is perhaps a bit
too low. You can change it to eg. 5 minutes:

	echo 150 > /proc/sys/net/tux/keepalive_timeout

the timeout is normal. You have TUX_DEBUG enabled, this is why the timeout
shows up in the log. (running TUX_DEBUG-enabled kernels on production
boxes is not recommended, due to client-triggerable syslog messages.
TUX_DEBUG-disabled kernels are not supposed to produce any syslog messages
on any client-side behavior.)

> This does not happen when I do "telnet myhost 80" and enter "GET
> /index.html HTTP/1.0<enter><enter>". Maybe because I use HTTP 1.0 in
> my manual request?

exactly. HTTP/1.0 requests have keepalives default-off. HTTP/1.1 are
default-on keepalive.

> If I reload the index.html I get the reply "Request Timed Out". When I
> reload twice after this I get the same reply. But on the third time I
> get my index.html page again, which I can reload as often as I want
> until the timeout message in the systemlog shows up again and the the
> same behaviour start over again.

yep - Netscape doesnt appear to handle keepalives very well. Perhaps TUX
should just zap the connection instead of sending a RFC-conform 'Request
Timed Out' reply, in that case Netscape will just retry the request. I'll
test this now.

	Ingo