Proxy design

[rb...@covalent.net]

I have been spending a lot of time in the 1.3 and 2.0 proxies right now,
and here is the general design I am moving towards in 2.0.  Please realize
this is not a dictated course, this is just what I see as a potential
solution, and what I am implementing right now.  This is WAY open for
discusion.


Okay, Graham suggested that this should basically just pass through data
from the client to the back-end server, and then back the other way.  This
is great in principle, but it doesn't quite work, because Apache gets in
the way just a little bit.  So here's what I see:

Apache core accepts the request, and translates it into an internal
representation for Apache.

mod_proxy notices that it is a proxy request in the post_read_request
phase, and sets some flags that it is currently setting in the translate
name phase.  The reason for the phase change, is that we want to detect
that this is a proxy request ASAP, and post_read does that.

in the handler phase, we just connect to the back-end server, and
re-create the request from the headers_in field.  To do this, I think we
can create a conn_rec, and setup a VERY small filter chain.  This will let
us take advantage of all the core code to format headers into a data
stream and send them to the back-end server.

Then we setup a proxy filter chain that consists of
	proxy_header_filter  (which header filter is added depends on the
protocol we are proxying.)
	cache_filter

and we send an EOS down the filter stack. The EOS just means that the
handler is done, and the filters take over.

In the proxy_header_filter, we read the headers from the back-end server,
and setup the real request_rec with the correct information, such as
content-type, content-length, and so on.  Those headers need to be put
into the correct fields so that Apache can deal with them intelligently.

We can take advantage of a lot of Apache's core input filters to get this
stuff in the right format, and remove some duplicated code at the same
time.

Once we have read all the headers, we read the correct amount of data from
the origin server (hopefully using ap_get_client_block) and send that down
the filter stack.  After we have read this request fully, we send the EOS
down the stack, and we are done.

I should know if the filters will work later today.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------