Draft: Feature/rapid cdn request pass thru
Initial cleanup phase: all components used in the HTTP pass thru traffic shall be interconnected with the highest possible HTTP protocol:
- frontend haproxy
- ATS
- backend haproxy
The shall use SSL with locally generated certificates from local partition.
Tasks:
-
make local caucase on each frontend node -
replace existing self-signed certificates with caucase ones -
switch internal connections of fronted haproxy, backend haproxy and ATS to SSLs coming from one CA with validation -
local caucased recreation on service change - the lock count is not typed it, in depends on the registered services
- caucased directory is a hash of services using it, changes each time service change
- service change is:
- addition
- removal
- name change
-
improve test coverage -
for cluster with HTTP/1.1, HTTP/2 and HTTP/3 assert behavior of client with HTTP/1.1, HTTP/2 and HTTP/3, as currently it's not correctly checked -
cover websockets against real websocket backend, with connection upgrades, etc
-
Feature phase: like incoming connections, outgoing connections from backend haproxy shall use the best possible protocol, which can be downgraded per slave with parameters:
-
make connection between frontend, ATS and backend haproxy with SSL with verification of the server, only one link -
drop https-urlfully
-
-
use ATS correctly - really pass a KEY as real URL coming from the client without any manipulation, as currently it’s very messy!
-
use the highest possible protocol between frontend haproxy, backend haproxy and ATS, the max being HTTP/2, but ceiled by incoming request protocol -
!!! TENTATIVE !!! use highest possible protocol between backend haproxy and origin -
assure that it does not impact websocket on HTTP/1.1 -
assure enable-http2=false is honored -
assure enable-http3=false is honored -
check behavior of client using low protocol version -
websocket-h2 - new parameter, by default true
-
enable-backend-http2 - new parameter, by default true
-
Edited by Łukasz Nowak