Re: mod_proxy_websocket
On Mar 22, 2013, at 4:54 PM, Stefan Fritsch s...@sfritsch.de wrote: On Tuesday 19 March 2013, Jim Jagielski wrote: This would be EXTREMELY easy just using -notes But having to do a hash lookup in -notes on every read from the network seems rather inefficient to me. I think an optional function or a field in conn_rec would be better. If we added field in conn_rec, we could also add a number of other flags for things that may be interesting and don't have a flag right now. E.g. - is HTTP - was updated from HTTP to something else - connection to next hop is encrypted - user-agent sees https (for URLs); IIRC there was something in the mod_spdy slides that something like this is missing. - httpd is client / connection is to a remote server - lingering close should be shortened (used by mod_reqtimeout. Right now, this is also a note). Yeah, this is all stuff that we need to think about for trunk and most of the above has been suggested in other threads. Ideally, we should add these to trunk's STATUS. My only concern are features/additions that we need now, relying on features that break API for 2.4.x...
Re: mod_proxy_websocket
Indeed it does and without issue. On 2013-03-20, at 7:31 AM, Jim Jagielski wrote: I would try the latest version on trunk. It should automatically disable the reqtimeout filter. On Mar 19, 2013, at 7:22 PM, Jamie Johnson jej2...@gmail.com wrote: For those of us not familiar how would this be accomplished? Is it just config or is there also some dev that needs to happen? On Mar 19, 2013 9:09 AM, Jim Jagielski j...@jagunet.com wrote: This would be EXTREMELY easy just using -notes On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
Perfect! Thx! On Mar 23, 2013, at 12:15 PM, Nathan Quinlan nathan.quin...@gmail.com wrote: Indeed it does and without issue. On 2013-03-20, at 7:31 AM, Jim Jagielski wrote: I would try the latest version on trunk. It should automatically disable the reqtimeout filter. On Mar 19, 2013, at 7:22 PM, Jamie Johnson jej2...@gmail.com wrote: For those of us not familiar how would this be accomplished? Is it just config or is there also some dev that needs to happen? On Mar 19, 2013 9:09 AM, Jim Jagielski j...@jagunet.com wrote: This would be EXTREMELY easy just using -notes On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
On Tuesday 19 March 2013, Jim Jagielski wrote: This would be EXTREMELY easy just using -notes But having to do a hash lookup in -notes on every read from the network seems rather inefficient to me. I think an optional function or a field in conn_rec would be better. If we added field in conn_rec, we could also add a number of other flags for things that may be interesting and don't have a flag right now. E.g. - is HTTP - was updated from HTTP to something else - connection to next hop is encrypted - user-agent sees https (for URLs); IIRC there was something in the mod_spdy slides that something like this is missing. - httpd is client / connection is to a remote server - lingering close should be shortened (used by mod_reqtimeout. Right now, this is also a note). That's just ideas, currently. I haven't really thought this through. About your current solution of removing the reqtimeout from the filter chain: There is a long standing open issue that the edge connection filter cannot be removed, see STATUS. I haven't really investigated if this affects mod_wstunnel, but someone should check that if we intend to keep this solution. On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
On 22 Mar 2013, at 10:54 PM, Stefan Fritsch s...@sfritsch.de wrote: On Tuesday 19 March 2013, Jim Jagielski wrote: This would be EXTREMELY easy just using -notes But having to do a hash lookup in -notes on every read from the network seems rather inefficient to me. I think an optional function or a field in conn_rec would be better. If we added field in conn_rec, we could also add a number of other flags for things that may be interesting and don't have a flag right now. E.g. - is HTTP - was updated from HTTP to something else - connection to next hop is encrypted - user-agent sees https (for URLs); IIRC there was something in the mod_spdy slides that something like this is missing. - httpd is client / connection is to a remote server - lingering close should be shortened (used by mod_reqtimeout. Right now, this is also a note). That's just ideas, currently. I haven't really thought this through. +1. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: mod_proxy_websocket
I would try the latest version on trunk. It should automatically disable the reqtimeout filter. On Mar 19, 2013, at 7:22 PM, Jamie Johnson jej2...@gmail.com wrote: For those of us not familiar how would this be accomplished? Is it just config or is there also some dev that needs to happen? On Mar 19, 2013 9:09 AM, Jim Jagielski j...@jagunet.com wrote: This would be EXTREMELY easy just using -notes On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
This would be EXTREMELY easy just using -notes On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
For those of us not familiar how would this be accomplished? Is it just config or is there also some dev that needs to happen? On Mar 19, 2013 9:09 AM, Jim Jagielski j...@jagunet.com wrote: This would be EXTREMELY easy just using -notes On Mar 19, 2013, at 9:03 AM, Jim Jagielski j...@jagunet.com wrote: On Mar 18, 2013, at 4:56 PM, Stefan Fritsch s...@sfritsch.de wrote: Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions. Actually, I think that's the most logical solution...
Re: mod_proxy_websocket
On Wednesday 06 March 2013, Micha Lenk wrote: However, using mod_websocket from the mentioned Github location, I discovered that it has timeout issues when mod_reqtimeout is loaded too (unless request body timeouts are disabled). Apparently mod_reqtimeout now enforces timeouts in non-blocking I/O mode independently from apr_socket timeouts. I.e. the call to apr_socket_timeout_set() in mod_websocket.c doesn't disable all active timeouts anymore. The result is that the websocket is disconnected after 20 seconds (RequestReadTimeout default for body timeout). mod_reqtimeout only touches http connections and has also special handling to avoid touching CONNECT requests. But since websocket connections start their live as http, I see that there may be a problem. Is there a way for mod_reqtimeout to determine that a connection has been upgraded, i.e. that it is no longer http? If no, maybe we should extend the conn_rec to provide that information. Alternatively, mod_reqtimeout could offer an API to allow modules to disable it. But I think that is the worse of the two solutions.
Re: mod_proxy_websocket/tunnel
Great I'm going to try that as well. Can you provide the process...anything would be appreciated On Mar 17, 2013 12:06 AM, Nathan Quinlan nathan.quin...@gmail.com wrote: I was able to backport this into 2.4.4 in less than an hour. Fortunately it isn't that different from trunk and I'm not a C guy. On 2013-03-15, at 11:49 PM, jej2003 wrote: Is it possible to build this module to run on an existing httpd 2.2.22 instance? -- View this message in context: http://apache-http-server.18135.n6.nabble.com/mod-proxy-websocket-tp5004158p5004434.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_proxy_websocket/tunnel
I'm sure there is documentation about how to add a module and build it as part of the httpd compile but I basically just: 1) copied over the module into 2.4.4 src. 2) searched for mod_proxy_ajp and added the equivalent mod_proxy_wstunnel entry in all files 3) make make install. Discovered that on adding a new module ./buildconf and then ./configure required 4) Run, find out that a function was undefined. 5) Searched for the missing function and then proceed to diff merge the changes from trunk into 2.4.4 6) Just copied over mod_proxy_httpd.c as the changes were numerous 7) build and done. On 2013-03-17, at 6:25 AM, Jamie Johnson wrote: Great I'm going to try that as well. Can you provide the process...anything would be appreciated On Mar 17, 2013 12:06 AM, Nathan Quinlan nathan.quin...@gmail.com wrote: I was able to backport this into 2.4.4 in less than an hour. Fortunately it isn't that different from trunk and I'm not a C guy. On 2013-03-15, at 11:49 PM, jej2003 wrote: Is it possible to build this module to run on an existing httpd 2.2.22 instance? -- View this message in context: http://apache-http-server.18135.n6.nabble.com/mod-proxy-websocket-tp5004158p5004434.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_proxy_websocket/tunnel
thanks I'll give this a try. Is there any chance of getting this officially ported back to 2.4? I think there are a lot of folks that would be interested in this. On Sun, Mar 17, 2013 at 8:56 AM, Nathan Quinlan nathan.quin...@gmail.comwrote: I'm sure there is documentation about how to add a module and build it as part of the httpd compile but I basically just: 1) copied over the module into 2.4.4 src. 2) searched for mod_proxy_ajp and added the equivalent mod_proxy_wstunnel entry in all files 3) make make install. Discovered that on adding a new module ./buildconf and then ./configure required 4) Run, find out that a function was undefined. 5) Searched for the missing function and then proceed to diff merge the changes from trunk into 2.4.4 6) Just copied over mod_proxy_httpd.c as the changes were numerous 7) build and done. On 2013-03-17, at 6:25 AM, Jamie Johnson wrote: Great I'm going to try that as well. Can you provide the process...anything would be appreciated On Mar 17, 2013 12:06 AM, Nathan Quinlan nathan.quin...@gmail.com wrote: I was able to backport this into 2.4.4 in less than an hour. Fortunately it isn't that different from trunk and I'm not a C guy. On 2013-03-15, at 11:49 PM, jej2003 wrote: Is it possible to build this module to run on an existing httpd 2.2.22 instance? -- View this message in context: http://apache-http-server.18135.n6.nabble.com/mod-proxy-websocket-tp5004158p5004434.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_proxy_websocket/tunnel
I was able to get this working locally as well, thanks for the steps. On Sun, Mar 17, 2013 at 9:57 AM, Jamie Johnson jej2...@gmail.com wrote: thanks I'll give this a try. Is there any chance of getting this officially ported back to 2.4? I think there are a lot of folks that would be interested in this. On Sun, Mar 17, 2013 at 8:56 AM, Nathan Quinlan nathan.quin...@gmail.comwrote: I'm sure there is documentation about how to add a module and build it as part of the httpd compile but I basically just: 1) copied over the module into 2.4.4 src. 2) searched for mod_proxy_ajp and added the equivalent mod_proxy_wstunnel entry in all files 3) make make install. Discovered that on adding a new module ./buildconf and then ./configure required 4) Run, find out that a function was undefined. 5) Searched for the missing function and then proceed to diff merge the changes from trunk into 2.4.4 6) Just copied over mod_proxy_httpd.c as the changes were numerous 7) build and done. On 2013-03-17, at 6:25 AM, Jamie Johnson wrote: Great I'm going to try that as well. Can you provide the process...anything would be appreciated On Mar 17, 2013 12:06 AM, Nathan Quinlan nathan.quin...@gmail.com wrote: I was able to backport this into 2.4.4 in less than an hour. Fortunately it isn't that different from trunk and I'm not a C guy. On 2013-03-15, at 11:49 PM, jej2003 wrote: Is it possible to build this module to run on an existing httpd 2.2.22 instance? -- View this message in context: http://apache-http-server.18135.n6.nabble.com/mod-proxy-websocket-tp5004158p5004434.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_proxy_websocket/tunnel
I was able to backport this into 2.4.4 in less than an hour. Fortunately it isn't that different from trunk and I'm not a C guy. On 2013-03-15, at 11:49 PM, jej2003 wrote: Is it possible to build this module to run on an existing httpd 2.2.22 instance? -- View this message in context: http://apache-http-server.18135.n6.nabble.com/mod-proxy-websocket-tp5004158p5004434.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: mod_proxy_websocket/tunnel
From my somewhat limited testing, so far things look good... Who can provide some more rigorous tests?
Re: mod_proxy_websocket/tunnel
On 08.03.2013 13:40, Jim Jagielski wrote: From my somewhat limited testing, so far things look good... Who can provide some more rigorous tests? I never used them myself, but http://autobahn.ws/ provides a broadly used test suite. Mark T. uses it for his development of Websockets for Tomcat. Autobahn also provides a websocket server you could maybe use as a back end, but you could also try Tomcat 7. Since 7.0.27 it comes with a websocket implementation that passes the Autobahn test suite. Currently there are three WS example apps bundled, echo, chat and snake. A short intro is available under http://tomcat.apache.org/tomcat-7.0-doc/web-socket-howto.html Mark T. is now working on a websocket impl for TC trunk which conforms to the upcoming WS programming API standard in Java, but that's work in progress. HTH Rainer
Re: mod_proxy_websocket
Today, I think that I will actually rename it to mod_proxy_tunnel, which is a more accurate description of the module... I expect it will be used mostly to proxy tunnel websockets, but still, the new name is better. On Mar 6, 2013, at 8:51 AM, Jim Jagielski j...@jagunet.com wrote: As trunk and commit watchers may have noticed, I've added a rough mod_proxy_websocket extension module to trunk. The basic idea was to have a simple tunnel that could be used to proxy websocket requests, and that's the design... I still need to add the basic 'send initial rec'd headers' to the backend to get it functional. Also not sure if a true tunnel makes the most sense, but it's a start ;)
Re: mod_proxy_websocket
Hi Jim, On 03/07/2013 11:45 AM CEST +02:00, Jim Jagielski wrote: Today, I think that I will actually rename it to mod_proxy_tunnel, which is a more accurate description of the module... I expect it will be used mostly to proxy tunnel websockets, but still, the new name is better. I would prefer mod_proxy_websocket over mod_proxy_tunnel. The term 'tunnel' is a bit to generic in this context. E.g. it is certainly unable to tunnel RPC (bugzilla issue #40029), so it is definitely not a generic tunnel. Regards, Micha
Re: mod_proxy_websocket
It's an http* tunnel. On Mar 7, 2013, at 6:03 AM, Micha Lenk mi...@lenk.info wrote: Hi Jim, On 03/07/2013 11:45 AM CEST +02:00, Jim Jagielski wrote: Today, I think that I will actually rename it to mod_proxy_tunnel, which is a more accurate description of the module... I expect it will be used mostly to proxy tunnel websockets, but still, the new name is better. I would prefer mod_proxy_websocket over mod_proxy_tunnel. The term 'tunnel' is a bit to generic in this context. E.g. it is certainly unable to tunnel RPC (bugzilla issue #40029), so it is definitely not a generic tunnel. Regards, Micha
Re: mod_proxy_websocket
Hi Jim, On 03/07/2013 03:08 PM CEST +02:00, Jim Jagielski wrote: It's an http* tunnel. Yet I bet it isn't able to tunnel RPC over HTTP, as described in Bugzilla #40029. If my humble opinion counts, please stick with mod_proxy_websocket. Micha
Re: mod_proxy_websocket
The name doesn't matter... I had already changed the name but if people don't like it, I'm fine w/ a new name (or names) being suggested. On Mar 7, 2013, at 9:18 AM, Micha Lenk mi...@lenk.info wrote: Hi Jim, On 03/07/2013 03:08 PM CEST +02:00, Jim Jagielski wrote: It's an http* tunnel. Yet I bet it isn't able to tunnel RPC over HTTP, as described in Bugzilla #40029. If my humble opinion counts, please stick with mod_proxy_websocket. Micha
Re: mod_proxy_websocket
Hi Jim, On 03/06/2013 02:51 PM CEST +02:00, Jim Jagielski wrote: As trunk and commit watchers may have noticed, I've added a rough mod_proxy_websocket extension module to trunk. The basic idea was to have a simple tunnel that could be used to proxy websocket requests, and that's the design... I still need to add the basic 'send initial rec'd headers' to the backend to get it functional. Also not sure if a true tunnel makes the most sense, but it's a start ;) How is your module related to this module? https://github.com/disconnect/apache-websocket I guess yours is intended to proxy websockets, whereas the latter is intended to handle websockets locally somehow. However, using mod_websocket from the mentioned Github location, I discovered that it has timeout issues when mod_reqtimeout is loaded too (unless request body timeouts are disabled). Apparently mod_reqtimeout now enforces timeouts in non-blocking I/O mode independently from apr_socket timeouts. I.e. the call to apr_socket_timeout_set() in mod_websocket.c doesn't disable all active timeouts anymore. The result is that the websocket is disconnected after 20 seconds (RequestReadTimeout default for body timeout). How does your module handle these timeouts? Regards, Micha
Re: mod_proxy_websocket
Yes, from what I can see, that module is a Websockets handler and not a proxy module, per se. I think there are some suggestions to actually have it donated to the ASF... Mine is simply designed to allow httpd to proxy websocket requests, nothing else. I see the 2 as complimentary. On Mar 6, 2013, at 10:01 AM, Micha Lenk mi...@lenk.info wrote: Hi Jim, On 03/06/2013 02:51 PM CEST +02:00, Jim Jagielski wrote: As trunk and commit watchers may have noticed, I've added a rough mod_proxy_websocket extension module to trunk. The basic idea was to have a simple tunnel that could be used to proxy websocket requests, and that's the design... I still need to add the basic 'send initial rec'd headers' to the backend to get it functional. Also not sure if a true tunnel makes the most sense, but it's a start ;) How is your module related to this module? https://github.com/disconnect/apache-websocket I guess yours is intended to proxy websockets, whereas the latter is intended to handle websockets locally somehow. However, using mod_websocket from the mentioned Github location, I discovered that it has timeout issues when mod_reqtimeout is loaded too (unless request body timeouts are disabled). Apparently mod_reqtimeout now enforces timeouts in non-blocking I/O mode independently from apr_socket timeouts. I.e. the call to apr_socket_timeout_set() in mod_websocket.c doesn't disable all active timeouts anymore. The result is that the websocket is disconnected after 20 seconds (RequestReadTimeout default for body timeout). How does your module handle these timeouts? Regards, Micha
Re: mod_proxy_websocket
Hi Jim, Am 06.03.2013 18:22, schrieb Jim Jagielski: How does your module handle [the mod_reqtimeout] timeouts? Still unanswered,,, Regards, Micha
