Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Rainer Jung 

Am 08.02.2018 um 19:50 schrieb Mark Nenadov:

according to the docs, you can actually specify the protocol:

https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :

"In fact the module can be used to upgrade to other protocols, you can set the 
upgrade parameter in the ProxyPass directive to allow the module to accept other 
protocol."

 From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :

"Parameter "upgrade", default "WebSocket": Protocol accepted in the Upgrade header 
by mod_proxy_wstunnel. See the documentation of this module for more details."

So maybe setting "upgrade=websocket" as a ProxyPass parameter might already 
achieve what Mark is looking for?

Regards
Jens


Hi Jens,

I saw this upgrade parameter in the manual earlier and tried it. But
it doesn't appear to be valid (manual reference notwithstanding),
config test complains about a syntax error when I add it, even with
providing the default value.

The manual isn't very clear about it.

The documentation for the mod_proxy_wstunnel
(https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
suggests that it should be upgrade=ANY or upgrade=NONE. But I still
can't get configtest to pass with it set to ANY or NONE either.


Can you post one of your failed configs and the error message?

It should be something like

< LocationMatch "/somewhere" >
  ProxyPass wss://192.168.1.77/some_url_on_tomcat upgrade=websocket
< / LocationMatch >

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Mark Nenadov 
> according to the docs, you can actually specify the protocol:
>
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :
>
> "In fact the module can be used to upgrade to other protocols, you can set 
> the upgrade parameter in the ProxyPass directive to allow the module to 
> accept other protocol."
>
> From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :
>
> "Parameter "upgrade", default "WebSocket": Protocol accepted in the Upgrade 
> header by mod_proxy_wstunnel. See the documentation of this module for more 
> details."
>
> So maybe setting "upgrade=websocket" as a ProxyPass parameter might already 
> achieve what Mark is looking for?
>
> Regards
> Jens

Hi Jens,

I saw this upgrade parameter in the manual earlier and tried it. But
it doesn't appear to be valid (manual reference notwithstanding),
config test complains about a syntax error when I add it, even with
providing the default value.

The manual isn't very clear about it.

The documentation for the mod_proxy_wstunnel
(https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
suggests that it should be upgrade=ANY or upgrade=NONE. But I still
can't get configtest to pass with it set to ANY or NONE either.

Thanks,
~Mark

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Mark Nenadov 
On Thu, Feb 8, 2018 at 1:33 PM,   wrote:
> You are probably proxying with mod_proxy_wstunnel. It seems to me that 
> "Upgrade: WebSocket" is hard-coded in that module.
>
> Regards,
>
> Rainer

Hi Rainer,

Thanks. Yes, I am using mod_proxy_wstunnel and it appears that that is
the issue.

~Mark

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Jens-U. Mozdzen 

Hi Rainer, hi Mark,

Zitat von Rainer Jung :

Hi Mark,

Am 08.02.2018 um 16:49 schrieb Mark Nenadov:
Hello, I have an operational setup where Apache httpd is proxying  
secure websockets traffic to an Apache Tomcat server. In other  
words, I'm using ProxyPass to pass traffic along to a WSS url.


I'm now having some issues trying to throw mod_headers into the  
mix. I'm attempting to manipulate the "Upgrade" header like so in  
my Apache httpd Virtual Host:


< LocationMatch "/somewhere" >
  RequestHeader set Upgrade websocket
  ProxyPass wss://192.168.1.77/some_url_on_tomcat  


< / LocationMatch >

So, supposing the client sends something funky for Upgrade like  
"WebSocket" (as an older version of a certain websocket library  
does), this RequestHeader directive should, by my understanding,  
replace it with "websocket".


However, when I place %{Upgrade}i in both my Apache httpd and  
Apache Tomcat access logs, I'm finding that the modified Upgrade  
header appears only in my httpd access logs, Tomcat says it is  
getting the original unmodified value!


This is rather perplexing to me as my understanding is that  
RequestHeader should permanently alter that request header. The  
Tomcat setup I have is very straightforward and there should be no  
surprises there.


I've tried changing my RequestHeader usage to do an unset and add  
I've also tried adding the "early" directive to the end of  
RequestHeader, but that does not alter the behavior.


It sure seems like the problem is with how Apache httpd is passing  
things along somehow, but my research hasn't come up with an answer  
that explains it or offers a resolution. Am I missing something here?


Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24


You are probably proxying with mod_proxy_wstunnel. It seems to me  
that "Upgrade: WebSocket" is hard-coded in that module.


according to the docs, you can actually specify the protocol:

https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :

"In fact the module can be used to upgrade to other protocols, you can  
set the upgrade parameter in the ProxyPass directive to allow the  
module to accept other protocol."


From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :

"Parameter "upgrade", default "WebSocket": Protocol accepted in the  
Upgrade header by mod_proxy_wstunnel. See the documentation of this  
module for more details."


So maybe setting "upgrade=websocket" as a ProxyPass parameter might  
already achieve what Mark is looking for?


Regards
Jens


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Rainer Jung 

Hi Mark,

Am 08.02.2018 um 16:49 schrieb Mark Nenadov:
Hello, I have an operational setup where Apache httpd is proxying secure 
websockets traffic to an Apache Tomcat server. In other words, I'm using 
ProxyPass to pass traffic along to a WSS url.


I'm now having some issues trying to throw mod_headers into the mix. I'm 
attempting to manipulate the "Upgrade" header like so in my Apache httpd 
Virtual Host:


< LocationMatch "/somewhere" >
   RequestHeader set Upgrade websocket
   ProxyPass wss://192.168.1.77/some_url_on_tomcat 


< / LocationMatch >

So, supposing the client sends something funky for Upgrade like 
"WebSocket" (as an older version of a certain websocket library does), 
this RequestHeader directive should, by my understanding, replace it 
with "websocket".


However, when I place %{Upgrade}i in both my Apache httpd and Apache 
Tomcat access logs, I'm finding that the modified Upgrade header appears 
only in my httpd access logs, Tomcat says it is getting the original 
unmodified value!


This is rather perplexing to me as my understanding is that 
RequestHeader should permanently alter that request header. The Tomcat 
setup I have is very straightforward and there should be no surprises there.


I've tried changing my RequestHeader usage to do an unset and add I've 
also tried adding the "early" directive to the end of RequestHeader, but 
that does not alter the behavior.


It sure seems like the problem is with how Apache httpd is passing 
things along somehow, but my research hasn't come up with an answer that 
explains it or offers a resolution. Am I missing something here?


Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24


You are probably proxying with mod_proxy_wstunnel. It seems to me that 
"Upgrade: WebSocket" is hard-coded in that module.


Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] websocket header not passing a long with ProxyPass and mod_headers

2018-02-08 Thread Mark Nenadov 
Hello, I have an operational setup where Apache httpd is proxying secure
websockets traffic to an Apache Tomcat server. In other words, I'm using
ProxyPass to pass traffic along to a WSS url.

I'm now having some issues trying to throw mod_headers into the mix. I'm
attempting to manipulate the "Upgrade" header like so in my Apache httpd
Virtual Host:

< LocationMatch "/somewhere" >
  RequestHeader set Upgrade websocket
  ProxyPass wss://192.168.1.77/some_url_on_tomcat
< / LocationMatch >

So, supposing the client sends something funky for Upgrade like "WebSocket"
(as an older version of a certain websocket library does), this
RequestHeader directive should, by my understanding, replace it with
"websocket".

However, when I place %{Upgrade}i in both my Apache httpd and Apache Tomcat
access logs, I'm finding that the modified Upgrade header appears only in
my httpd access logs, Tomcat says it is getting the original unmodified
value!

This is rather perplexing to me as my understanding is that RequestHeader
should permanently alter that request header. The Tomcat setup I have is
very straightforward and there should be no surprises there.

I've tried changing my RequestHeader usage to do an unset and add I've also
tried adding the "early" directive to the end of RequestHeader, but that
does not alter the behavior.

It sure seems like the problem is with how Apache httpd is passing things
along somehow, but my research hasn't come up with an answer that explains
it or offers a resolution. Am I missing something here?

Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24

Many thanks,
~Mark