[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: tux as HTTP-parser



On Tue, 25 Sep 2001, Thiemo Voigt wrote:

> My aim is to use the HTTP parsing provided by tux, direct all accepted
> requests to Apache and reset the non-accepted requests.

i like your approach, and it only needs some cleanup. I'd suggest adding a
new tunable, eg. tux_redirect_all. Then do something like this at the
'error:' label:

	if (tux_redirect_all) {
		req->error = 3;
		zap_request(req);
	} else {
		... the current code ...
	}

zap_request() is a central function to zap a request effectively and
immediately.

> In order to make tux sent the RST to the peer I call
> tcp_send_active_reset (which I have export so it is found in the
> symbol table) before the clear_keepalive.

Is there any good reason to send a RST instead of closing the socket
gracefully? If a keepalive connection sends an incorrect request after a
correct request then a RST can mess up even the correct request, leading
to all sorts of irreproducible and hard to debug problems.

plus, at the 'From this point on' place do something like this:

	if (tux_redirect_all) {
		clear_keepalive(req);
		req->error = 1;
		return -1;
	}

this should result either in a redirect to user-space, or an error message
to the client if the secondary server is not running for whatever reason.

	Ingo





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []