On Saturday, October 20, 2001, at 03:47 PM, William A. Rowe, Jr. wrote:
> From: "Chuck Murcko" <[EMAIL PROTECTED]> > Sent: Saturday, October 20, 2001 2:32 PM > > >> On Saturday, October 20, 2001, at 01:02 PM, Daniel Lopez wrote: >> >>> On Sat, Oct 20, 2001 at 11:16:10AM +0200, Graham Leggett wrote: >>>> Daniel Lopez wrote: >>>> >>>>> I need an additional hook to process headers before they are sent to >>>>> the >>>>> origin server in a reverse proxy configuration. >>>> >>>> Use mod_headers for this - it was modified to handle this behavior a >>>> while back. >>> >>> client <---> apache with reverse proxy <--> origin server >>> >>> mod_headers allows modification of headers between client and apache, >>> but >>> not headers between proxy and origin server. >>> >>>> Adding hooks to proxy is bad, because it means that this >>>> functionality >>>> is limited to proxy, and is not available to the rest of the server. >>> >>> But this is proxy specific functionality :) >> >> Yes, this is specifically used by the proxy's "client side", connecting >> to an origin server. Sorry I was not clearer the first time. The sweet >> way to do this would be having the ability to set up a second filter >> chain on the client side. It seems hard to justify doing that work only >> for the proxy though. > > Daniel's proposed hook would be the perfect point to allow you to insert > yourself into the origin filter chain, given the right args. No? > Yes. > We should already have two filter chains, one that proxy retrieves the > content from, and one that the server is using to fulfill the request. > [Except, perhaps, with a straight-through CONNECT proxy.] > Definitely no 2nd chain for CONNECT. The symmetry of filters in general has gotten much better since the first beta, but I believe that inserting FIXUP_HEADERS_OUT into the proxy's output filter chain (the one used for connecting to origin servers) still won't do the trick. Daniel's hook solves this problem nicely for proxy. Mod_headers is symmetric (can do the same ops on its input and output side) now, but lacks an efficient way to change its rules on a per request basis. And IIUC hooks are in part a method of providing custom processing "taps" in a filter chain. If we were designing something intended to be a network node rather than a server, something that was as likely to make an outbound connection as service an inbound one, I think we would build filters a bit differently. But we're not doing that for the general case here. So I think the hook is a good solution. Chuck
