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
<thomas.r.w.eck...@gmail.com>wrote:
> 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
>
>
>
