httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Eckert <>
Subject Re: ProxyPassReverseCookieDomain and non constant arguments
Date Mon, 22 Apr 2013 08:33:50 GMT
Any news here ? I would like this to get included since it fixes what I
think is a real lack of usability - see my previous example as to the 'why'
and 'how'.

On Thu, Apr 4, 2013 at 11:34 AM, Thomas Eckert

> Suppose you have several balancers defined, each with multiple workers.
> Now you want to rewrite all cookies from all servers, no matter the
> hostname the client requested the content under.
> This means that - at time of configuration - you don't know the domain of
> the content server you want to specify the directive for (1st argument to
> ProxyPassReverseCookieDomain). This *might* be solved by iterating over all
> domains and writing the directive for every single entry but this is surely
> not considered 'good' style and absolutely not something users with large
> setups want to do.
> The second problem is that - at time of configuration - you don't know the
> hostname you have to rewrite the cookie to. It has to be the hostname the
> client requested the content for, since only then will (or at least should)
> it be transmitted by the client's agent in subsequent requests. This would
> be solved by using %{HTTP_HOST} *if* that worked here. I expected it to but
> after checking the code for rewriting the cookies I got the impression the
> second argument to ProxyPassReverseCookieDomain would simply be copied
> unchanged into the cookie without any previous
> parsing/translation/substitution. I tried using %{HTTP_HOST} as second
> argument - inside a <VirtualHost> - but it was not replaced by the
> VirtualHost's ServerName or one of it's aliases and instead got printed
> into the cookie as "Domain=%{HTTP_HOST}" (2.4.4 of course)
> The idea behind the patches is to be able to specify something like
> <Proxy balancer://cd107d9706d71153bafd4ab15f1c6b5d>
>         BalancerMember http://server1.local
>         BalancerMember http://server2.local
> </Proxy>
> <VirtualHost>
>         ServerName reverseproxy.local
>         <Location />
>                 ProxyPass balancer://cd107d9706d71153bafd4ab15f1c6b5d/
> lbmethod=bybusyness
>                 ProxyPassReverse
> balancer://cd107d9706d71153bafd4ab15f1c6b5d/
>                 ProxyPassReverseCookieDomain
> balancer://cd107d9706d71153bafd4ab15f1c6b5d/
>         </Location>
> </VirtualHost>
> With the suggested patches this is all it takes to rewrite all the cookies
> to the correct domain names, independant of the number workers for each
> balancer and the hostname of the client requests. I found no way to do that
> with the existing code but I also feel like having missed something in
> regards to using %{HTTP_HOST} - maybe some behind-the-scenes-magic I am
> unaware of?
> On Thu, Apr 4, 2013 at 10:43 AM, Nick Kew <> wrote:
>> On 3 Apr 2013, at 08:52, Thomas Eckert wrote:
>> > I'm trying to make ProxyPassReverseCookieDomain understand two things
>> it apparently does not understand at the moment: accept 1) balancer names
>> and 2) variables as arguments. For the first problem I was able to come up
>> with a patch based on the code for the ProxyPassReverse directive (see
>> below).
>> >
>> > The second problem gives me headaches though. Suppose I would like to do
>> >   ProxyPassReverseCookieDomain balancer://foobar/ %{HTTP_HOST}
>> Why would you do that?  What backend application is setting cookies
>> with such a broken domain parameter as that?
>> > so the %{HTTP_HOST} expression is translated to the http host field of
>> the original client request. This is
>> The HTTP_HOST will always match the <VirtualHost> in which the reverse
>> proxy
>> is configured.  You can of course have as many virtualhosts as you want,
>> but I'm not convinced you need even that.
>> At a glance, your patch is unnecessary: you should get the same outcome
>> by just adding a ProxyPassReverseCookieDomain directive for each Host:
>> value you answer to.  Am I missing something?
>> --
>> Nick Kew

View raw message