You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2016/12/28 14:40:13 UTC
Fwd: [users@httpd] Web sockets & proxypass - No protocol handler was
valid for the URL
I guess we just got unlucky when this overlap was "fixed" before since
the order is not deterministic. I don't think we'll break anyone by
making wstunnell try first.
---------- Forwarded message ----------
From: Eric Covener <co...@gmail.com>
Date: Wed, Dec 28, 2016 at 9:36 AM
Subject: Re: [users@httpd] Web sockets & proxypass - No protocol
handler was valid for the URL
To: users@httpd.apache.org
On Wed, Dec 28, 2016 at 9:21 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Dec 28, 2016 at 1:32 PM, Adam Teale <ad...@believe.tv> wrote:
>> more detail from the error log:
>>
>> [Wed Dec 28 09:31:05.974744 2016] [proxy:debug] [pid 27844]
>> mod_proxy.c(1198): [client 127.0.0.1:54002] AH01143: Running scheme wss
>> handler (attempt 0)
>
> Looks like the request is missing the "Upgrade: WebSocket" header,
> which mod_proxy_wstunnel requires.
>
> From your configuration:
> ProxyPass /chat/stream/ wss://localhost:8000/chat/stream/
> it seems that /chat/stream/ is used for "normal" HTTP traffic (before
> the upgrade to WebSocket, possibly).
>
> Couldn't the pure WebSocket things be handled by another (inner) URL
> instead, so that the following could work:
> ProxyPass /chat/stream/ https://localhost:8000/chat/stream/
> ProxyPass /chat/stream/wss wss://localhost:8000/chat/stream/wss
>
Seems like we should setup wstunnel to go before http, so you could
then just configure both proxypasses and wstunnell would defer.
--
Eric Covener
covener@gmail.com
Re: [users@httpd] Web sockets & proxypass - No protocol handler was
valid for the URL
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 28, 2016 at 3:56 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Dec 28, 2016 at 9:54 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>> I guess we just got unlucky when this overlap was "fixed" before since
>>> the order is not deterministic. I don't think we'll break anyone by
>>> making wstunnell try first.
>>
>> I'm not sure the different schemes ("https" vs "wss") would allow both
>> handlers to run successively.
>>
>> r->filename is built once for all (proxy_trans), so mod_proxy_http
>> would DECLINE "wss://" and same for mod_proxy_wstunnel with
>> "https://".
>>
>> I proposed Upgrade handling in mod_proxy_http (a while ago, see [1]),
>> which is IMHO a better way to deal with HTTP Upgrading in httpd...
>
> Doh, I guess at least having the order be deterministic is not harmful
> so I will leave in r1776290
Yes, makes sense to try WebSocket first.
Maybe we should 426 (Upgrade Required) instead of DECLINing at AH02900, though.
Re: [users@httpd] Web sockets & proxypass - No protocol handler was
valid for the URL
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
> On Dec 28, 2016, at 9:56 AM, Eric Covener <co...@gmail.com> wrote:
>
> On Wed, Dec 28, 2016 at 9:54 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>> I guess we just got unlucky when this overlap was "fixed" before since
>>> the order is not deterministic. I don't think we'll break anyone by
>>> making wstunnell try first.
>>
>> I'm not sure the different schemes ("https" vs "wss") would allow both
>> handlers to run successively.
>>
>> r->filename is built once for all (proxy_trans), so mod_proxy_http
>> would DECLINE "wss://" and same for mod_proxy_wstunnel with
>> "https://".
>>
>> I proposed Upgrade handling in mod_proxy_http (a while ago, see [1]),
>> which is IMHO a better way to deal with HTTP Upgrading in httpd...
>
> Doh, I guess at least having the order be deterministic is not harmful
> so I will leave in r1776290
>
> Thanks for the hint.
>
> --
> Eric Covener
> covener@gmail.com
Re: [users@httpd] Web sockets & proxypass - No protocol handler was
valid for the URL
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 28, 2016 at 9:54 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> I guess we just got unlucky when this overlap was "fixed" before since
>> the order is not deterministic. I don't think we'll break anyone by
>> making wstunnell try first.
>
> I'm not sure the different schemes ("https" vs "wss") would allow both
> handlers to run successively.
>
> r->filename is built once for all (proxy_trans), so mod_proxy_http
> would DECLINE "wss://" and same for mod_proxy_wstunnel with
> "https://".
>
> I proposed Upgrade handling in mod_proxy_http (a while ago, see [1]),
> which is IMHO a better way to deal with HTTP Upgrading in httpd...
Doh, I guess at least having the order be deterministic is not harmful
so I will leave in r1776290
Thanks for the hint.
--
Eric Covener
covener@gmail.com
Re: [users@httpd] Web sockets & proxypass - No protocol handler was
valid for the URL
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Dec 28, 2016 at 3:40 PM, Eric Covener <co...@gmail.com> wrote:
> I guess we just got unlucky when this overlap was "fixed" before since
> the order is not deterministic. I don't think we'll break anyone by
> making wstunnell try first.
I'm not sure the different schemes ("https" vs "wss") would allow both
handlers to run successively.
r->filename is built once for all (proxy_trans), so mod_proxy_http
would DECLINE "wss://" and same for mod_proxy_wstunnel with
"https://".
I proposed Upgrade handling in mod_proxy_http (a while ago, see [1]),
which is IMHO a better way to deal with HTTP Upgrading in httpd...
[1] https://lists.apache.org/thread.html/e441f75818d07112e8122232440752bd8c27d5539b199bcd115e3b4e@%3Cdev.httpd.apache.org%3E