Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • slapos slapos
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Merge requests 127
    • Merge requests 127
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • nexedi
  • slaposslapos
  • Merge requests
  • !1944

Open
Created Dec 05, 2025 by Łukasz Nowak@lukeMaintainer5 of 17 tasks completed5/17 tasks
  • Report abuse
Report abuse

Draft: Feature/rapid cdn request pass thru

  • Overview 5
  • Commits 11
  • Changes 52

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
    • check behavior of connection upgrade for those protocol types

Note: work is postponed into https://lab.nexedi.com/luke/slapos/-/tree/feature/rapid-cdn-request-pass-thru-next

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, only one link
    • make https-url really working
      • describe in JSON schema how it is used
      • if https-url is present use it for requests incoming with https scheme
      • if https-only is true emit warning
      • do NOT make it passing differently via cluster
      • pass through the URL via ATS
  • 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
    • 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

Note: haproxy does not support HTTP/3 to the backends.

Edited Jan 16, 2026 by Łukasz Nowak
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: feature/rapid-cdn-request-pass-thru
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7