Proxy design

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.)

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related httpd.apache.org Links announce bugs cvs dev docs gui-dev modproxy-dev packagers testers Request more information about Pantek

        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