httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Handle Upgrade forwarding (protocol switch) in mod_proxy_http
Date Wed, 27 Jul 2016 16:09:35 GMT

since Upgrade is an HTTP/1 feature, I don't find it too twisted...

The primary goal would be to let the backend decide whether an Upgrade
is to be done, or otherwise continue with HTTP (still parsing the
response, filtering, caching, ...).

Currently we handle WebSocket tunneling only (in mod_proxy_wstunnel),
but it's dedicated to some configured URL(s), and if the client
chooses to not propose "Upgrade: WebSocket" on that URL(s) the request
is doomed (it falls back to the default_handler since the dedicated
scheme "ws(s)" won't be handled by anything else).

Actually mod_proxy_http has already all the state machine to handle
interim (e.g. 100-continue) and upgrade responses properly, it just
lacks the switch/tunneling to another protocol.

This what the two attached patches aim to.

The first one (mod_proxy-tunnel.patch) is to factorize all the
tunneling code(s) we currently have in proxy_connect and
proxy_wstunnel into proxy_util functions (namely
ap_proxy_tunnel_create(&tunnel, r, backconn) and
ap_proxy_tunnel_pump(tunnel, timeout)), and use them there.

The second one (mod_proxy_http-tunnel.patch) also uses them in
mod_proxy_http, where/when needed (a protocol switch is initiated by
the backend).
This is currently controlled/enabled only with "SetEnv
proxy-forward-upgrade" (we may not want to forward/tunnel Upgrades
unconditionally), it could be a ProxyUpgrade or so directive.

This is not limited to WebSocket forwarding, but it possibly would
obsolete mod_proxy_wstunnel...



View raw message