> > Yes, in fact that was the first approach I tried. Tut that would require > > modification of how the reverse proxy code works (which I would avoid if possible). > > Don't be scared to change how the proxy works - if the change is an > improvement, it should be included.
I want to go step by step :) I think even with a filtering architecture this step is better implemented as a hook. The next step would be adding a full filter chain that would have advantages like an SSL filter, compression, etc. > > Since I am just modifying headers, that is why I proposed this header fixup > > hook. > > If you're modifying headers, then your changes should be made to > mod_headers - otherwise you will end up with similar or the same code in > two modules, which is bad. (code in mod_headers expoiting your hook in > mod_proxy might be a way to this) No, I am not adding any code to mod_headers or mod_proxy, I just need the hook for a module I am writing. I think the hook has general value and as you suggest, mod_headers could be modified to take advantage of this new hook. mod_proxy could also take advantage of this (by adding all the X-Forward-* using that hook). > But backtracking a little - you said you needed this functionality to > modify the behavior of the X-Forwarded-For (and similar) headers. > Perhaps adding options to modify the X-* behavior is a better idea - the > fact that these headers are hard coded in and are not able to be > disabled is a bit bogus. > > What exactly are you trying to achieve? (Removing them? Changing them to > another value?) I have a requirement to add/change/unset headers going in the reverse proxy requests. These headers are not necessarily the same as r->headers_in so I cannot use existing hooks to modify those headers. I think is a good idea conceptually to have a point in which to modify the headers going to the backend server and that enables other modules like mod_header to take advantage of it
