Apache2 Loadbalancer с липкой сессией, только липкая для GET, а не POST
Я установил Apache 2.4.6 на Centos с mod_proxy
а также mod_headers
как описано в https://wiki.apache.org/httpd/LoadBalanceWithoutStickyCookie
Моя цель состоит в том, чтобы иметь липкие сессии, даже если внутренний сервер сам не генерирует куки сессии. В большинстве случаев это работает, но иногда запросы POST отправляются на другой сервер, который выполняют запросы GET.
Вот соответствующая часть моего файла конфигурации:
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set SSL-FRONTEND "yes"
## Proxy rules
ProxyRequests Off
ProxyPreserveHost On
# define a balancer
<Proxy balancer://mycluster>
BalancerMember http://backendserver1 route=route1 loadfactor=1 ttl=300
BalancerMember http://backendserver2 route=route2 loadfactor=1 ttl=300
Proxy
</Proxy>
# set a sticky cookie
Header add Set-Cookie "ROUTEID=sticky.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
ProxyPass / balancer://mycluster/ stickysession=ROUTEID
ProxyPassReverse / balancer://mycluster/
Когда я захожу на вкладку сети браузера и анализирую запросы, я вижу, что все GET имеют одинаковые файлы cookie ROUTEID (например, sticky.route1
), но запрос POST (здесь: csp-report, потому что мы используем Content Security Policy с URL-адресом отчета), иногда переходят на другой бэкэнд-сервер, и куки ROUTEID иногда здесь другие - например, sticky.route2
Я искал, но не смог найти решение до сих пор.
Кто-нибудь еще сталкивался с такой проблемой?
Не могли бы вы мне помочь, пожалуйста?
Спасибо и всего наилучшего,
Александр
Обновление 2019-01-16: похоже, что это на самом деле не проблема с apache или балансировкой нагрузки, а небольшая "проблема" с реализацией CSP в браузерах (проверено: FireFox и Chrome).
Похоже, что браузеры используют другую реализацию того, как они выполняют вызовы POST для report-url
что указано в Content-Security-Policy
заголовок: они просто не отправляют файлы cookie браузера для данного сайта report-url
, Таким образом, apache не может сопоставить этот запрос с другими запросами.
Если никто не придумает лучшего объяснения, я сам отвечу на этот вопрос.