Gunther Birznieks <[EMAIL PROTECTED]> writes:

> Although I don't have much to add to the conversation, I just wanted to say 
> that this is one of the most absolutely technically enlightening posts I've 
> read on the mod_perl list in a while. It's really interesting to finally 
> clarify this once and for all.

You bet - brilliant detective/expository work going on here!  
On a side note, a while back I was trying to coerce the TUX developers 
to rework their server a little.  I've included snippets of the 
email correspondence below:

============

From: Joe Schaefer <[EMAIL PROTECTED]>
Subject: Can tux 'proxy' for the user space daemon?
Date: 06 Oct 2000 13:32:10 -0400

It would be great if TUX is someday capable of 
replacing the "reverse proxy" kludge for mod_perl.
>From skimming the docs, it seems that 

TUX on port 80 +
apache on 8080

seems to fit this bill.

Question: In this setup, how does TUX behave wrt 
HTTP/1.1 keepalives to/from apache? 

Say apache is configured with mod_perl, and 
keepalives are disabled on apache.
Is TUX capable of maintaining keepalives on the 
browser <-> TUX connection, while maintaining a 
separate "pool" of (closed) TUX <-> apache connections?

If I'm way off here on how TUX works  (or will work),
please correct me!

Thanks.

==========

From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: Re: Can tux 'proxy' for the user space daemon?
Date: Sat, 7 Oct 2000 13:42:49 +0200 (CEST)

if TUX sees a request that is redirected to Apache, then all remaining
requests on the connection are redirected to Apache as well. TUX wont ever
see that connection again, the redirection works by 'trimming' all
previous input up to the request which goes to Apache, then the socket
itself is hung into Apache's listen socket, as if it came as a unique
request from the browser. This technique is completely transparent both to
Apache and to the browser. There is no mechanizm to 'bounce back' a
connection from Apache to TUX. (while connections do get bounced back and
forth between the kernel and user-space TUX modules.)

so eg. if the first 2 request within a single persistent HTTP/1.1
connection can be handled by TUX then it will be handled by TUX, and the
third (and all succeeding) requests will be redirected to Apache. Logging
will happen by TUX for the first 2 requests, and the remaining requests
will be logged by Apache.

==========

From: Joe Schaefer <[EMAIL PROTECTED]>
Subject: Re: Can tux 'proxy' for the user space daemon?
Date: 07 Oct 2000 19:52:31 -0400

Too bad- this means that HTTP/1.1 pages generated by an apache module won't 
benefit from TUX serving the images and stylesheet links contained therein. I 
guess disabling keepalives on the apache connection is (still) the only way 
to go.

I still think it would be cool if there was some hack to make this work- 
perhaps a TUX "gateway" module could do it?  Instead of handing off a 
request directly to apache, maybe a (user-space) TUX module could hand it 
off and then return control back to TUX when the page has been delivered.
Is such a "gateway" TUX module viable?

=========

From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: Re: Can tux 'proxy' for the user space daemon?
Date: Mon, 9 Oct 2000 11:42:57 +0200 (CEST)

depends on the complexity of the module. If it's simple functionality then
it might be best to write a dedicated TUX module for it, without Apache.

but if it's too complex then the same code that is used to hand a TCP
connection over to Apache can be used by Apache to send a connection back
to TUX as well. A new branch of the TUX system-call could handle this.

        Ingo

========


This might be worth looking in to (for linux anyway :).
-- 
Joe Schaefer

Reply via email to