On 11/04/2019 10:55 PM, Yann Ylavic wrote:
> On Mon, Nov 4, 2019 at 10:16 PM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>>
>>
>> On 11/04/2019 06:12 PM, Yann Ylavic wrote:
>>> On Mon, Nov 4, 2019 at 4:16 PM Ruediger Pluem <rpl...@apache.org> wrote:
>>>>
>>
>> Just that I get it correct:
>>
>> This would require something like
>>
>> ProxyPass / ws://hostname/
>> ProxyPass / http://hostname/
>>
>> to work and would only work with ProxyPass,
>
> Yes, that's the idea. I think the ProxyPass(es) order matters here
> though, because proxy_trans() walks the aliases in configuration
> order, so if it finds "http" first then "ws" will never be elected.
Exactly order is important here.
>
> We could be more clever, not sure it's worth it...
> My plan is to handle the "ws(s)" schemes in mod_proxy_http directly,
> using the new proxy tunnel interface of this commit to start tunneling
> if/when needed (according to the backend). Then mod_proxy_wstunnel
> would be obsolete.
Could make it easier, but not sure if it's worth it.
>
>> not with RewriteRules and [P] flag, correct?
>
> mod_rewrite wouldn't be concerned indeed, but today one can already:
>
> RewriteCond %{HTTP:Upgrade} websocket [NC]
> RewriteRule / ws://hostname/ [P]
>
> to make this work.
In parallel to
RewriteRule ^/(.*) http://hostname/$1 [P]
Good point. In this case order only matters from performance point of view in
order to limit the amount of RewriteRules
executed for the common case.
Regards
Rüdiger
