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 10.10.10.10:80>
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 <n...@webthing.com> 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
