Ну вот, а могли-бы успеть раньше опеннета
https://www.opennet.ru/opennews/art.shtml?num=49193

теперь TLSv1.3 можно использовать с BoringSSL.

Молодцы конечно
Но: почитал я про скучный ssl - оказалось, компания гугл реализует политику по замене стандартного ssl на свой собственный - скучный - ssl на всех своих продуктах, включая хром, андроид и все сервера
Мир никогда не будет прежним

чем BoringSSL отличается от:

LibreSSL, BearSSL и т.д.?

Подскажите, как в обычной версии (не +) реализовать StickySession?

В прошлом году искал и нашёл только один сторонний модуль, действительно ли не умеет в StickySession опенсорц нжинкс или я плохо искал?

Очередной убийца OpenSSL?

А что именно нужно от sticky ? Если выбрать upstream по куке, то реализовать можно через декод куки и мап на апстрим. Если что-то типа route, то через post_action...

Да, выбрать upstream, если я не путаю ничего.

Кластерное джава-приложение срёт куками клиенту, когда клиент снова посылает запрос, то мне надо маршрут до той самой ноды на бекенде, которая была до этого (ID ноды записано в куках и передаётся серверу)

Апачем это реализовано так:

 Header add Set-Cookie  "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"

        <Proxy balancer://appcluster>
               BalancerMember app1.com.local:8080 route=node1
               BalancerMember app2.com.local:8080 route=node2
                Order Deny,Allow
                Deny from none
                Allow from all

                ProxySet stickysession=ROUTEID

С удовольствием переведу на нжинкс, но не хватает знаний, кроме как через StickySession.

Столько изменений в webdav. Детских. Интересно, а что можно использовать для вебдав сервера? Ну то есть заточенного на скорость и безопасность? Чтоб не было ошибок в операциях копирования и перемещения файлов, чтобы были аклы на уровне самбы и скорость чтобы ограничивалась сетью и винчестером, а не 1 мбит в час при любых условиях...

Точное решение не дам :)) , но как-то так:

location / {
  set_decode_base64 $route_decoded $cookie_ROUTEID;
  proxy_pass http://${route_decoded};
}

Или даже так:

map $route_decoded $upstream {
  '~node1.*' 'app1.com.local:8080';
  '~node2.*' 'app2.com.local:8080';
}

location / {
  set_decode_base64 $route_decoded $cookie_ROUTEID;
  proxy_pass http://${upstream};
}

Интересно про маппинг, почитаю больше на досуге, спасибо!

По IP не вариант?

Нет, ибо ресурс внутренний и доступен только через ВПН.

Например, два клиента отклюичились одновременно, их адреса получили два новый клиента и в наследство к их адресам ещё и сессии.

А так как кровавый ынтырпрайз и юзеров сильно больше 1к, то коллизии неизбежны.

Там есть ещё айдишник самой сессии, конечно. Но всё равное не вариант, сессии не сохраняются.

Очередной убийца OpenSSL?

Не очередной, а, пожалуй, основной.

Какие киллерфичи? Чёт я пропустил

Просто написан аккуратнее, без всяких там хартблидов.

Можно еще штатными средствами:

upstream java_app{ server app1.com.local:8080; server app2.com.local:8080;

hash $route_decoded; }