• Jérome Perrin's avatar
    stack/erp5: implement Zope's rewrite rules in ERP5 balancer partition · 40ba5555
    Jérome Perrin authored
    The strategy for compatibility is that:
     - haproxy still listen on the same port as before, without rewrite rule.
       This is called "legacy" port.
     - for each frontend from request parameters, we introduce an haproxy
       frontend with a rewrite for the corresponding `internal-path`
       parameter.
     - the shared frontend instance is updated to use this new frontend
       entry from haproxy. This will cause a small downtime until the shared
       frontend is updated to the new URL on ERP5, but since this feature
       was not used, it's OK.
    
    Technical details are that we:
     - split haproxy config to have frontends and backends.
     - introduce one frontend in haproxy for each frontend from request
       parameters.
     - routing-rule-list argument is still honored the same way, globally
       and after path from frontend.
     - change the shared frontend requests to use "" type, no longer "zope"
       type.
     - we don't do automatic detection of /VirtualHostRoot in URL but always
       add it, because it could be used to trick zope into thinking it
       serves requests for an arbitrary host and do open redirects
     - before using the request's host header in virtualhost path, we check
       that it does not contain /, to prevent injection of virutalhost path
       elements through the host header.
     - we don't use the "path" parameter from shared frontend, because we
       want the frontend to be simple, so we don't want it to rewrite the
       request path (which is also the reason why we deprecated "zope" type)
     - the tests have changed a lot, because they were using what's now the
       "legacy" URL types, so we updated it to use the new URL types with
       all the /VirtualHostRoot/../ in path and also because they use IPv6
       URL, no longer IPv4
    40ba5555
haproxy.cfg.in 11.4 KB