> 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



Reply via email to