Graham Leggett writes:
> Kwindla Hultman Kramer wrote:
>
> > 1) It is not as flexible as one might like -- in particular, I added
> > an optional pattern-match field which is matched against the
> > request uri. If the uri satisfies the pattern match, the header
> > directive is applied. If not, not.
>
> What kind of pattern match field are you talking about?
>
> The header changes can be limited to certain places using RequestHeader
> inside <Location> directives. Is this enough for your application?
>
Yes. My patch that added ProxyRequestHeader and ProxyResponseHeader to
1.3 was written using pattern matches (regexec, to be precise) because
mod_proxy circa 1.3 handles only server-level directives.
If we are talking more generally about mod_headers features that would
be nice to have in 2.0, I have been playing around a little with the
idea of more powerful conditional header setting. Matching of a
mod_rewritish-style -- using variables like %{HTTP_HOST} -- could be
interesting.
Is that kind of functionality something you could see as useful in
mod_headers? Should I work a little on a prototype implementation?
<snip>
> The new mod_headers modifies incoming headers before the content
> handler, and outgoing headers after the content handler. This in theory
> should now work for you - can you check for me?
>
The code looks great. I will work some tonight on getting 2.0 built
and running on a test machine, so I can tell you for sure, in
practice.
Thanks again,
Kwindla
