> Am 02.09.2015 um 16:12 schrieb Eric Covener <cove...@gmail.com>: > > On Wed, Sep 2, 2015 at 10:09 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> But would it have an "Upgrade: + Connection:" header? I might be wrong, but >> I thought mod_proxy_wstunnel adds those headers before sending the request >> to a backend. So the core_ugprade_handler would not see those. > > > That module is not http-to-ws gateway, it's ws-to-ws, so the > normal/frontend request will have all of that stuff from the client.
But *unless* there is someone inside httpd that implements WebSocket *and* participates in protocol negotiations *and* is willing to directly upgrade to / ALPN select the WebSocket protocol, the protocol switching will never trigger. So, if we imagine some module wanting to implement WebSockets directly in httpd, what would it need to do? - If the client sends http/1.1 requests with "Upgrade: WebSocket", the module could propose WebSocket and let the server do the switch. It then gets control of the connection. Either it answers the WebSocket directly or uses a backend connection somewhere else, this will not be visible to the client. - If the client sends WebSocket in an ALPN negotiation and there is a module handling that for the SNI server given, it can take over the connection right away. - If the client expects some WebSocket on a connection *without* any HTTP/1.1 Upgrade or TLS ALPN magic, protocol negotiation does not trigger and all is as before. As a last resort, the server can always be configured with a "Protocols" without "WebSocket" in it and thus our new negotiation would do nothing. Perhaps you could make a more detailed description of where the implemented Protocols cause a problem? <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782