You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2013/03/06 14:51:38 UTC
mod_proxy_websocket
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/tunnel
Posted by Rainer Jung <ra...@kippdata.de>.
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/tunnel
Posted by Jamie Johnson <je...@gmail.com>.
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 <je...@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 <na...@gmail.com>wrote:
>
>> 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" <na...@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
Posted by Jamie Johnson <je...@gmail.com>.
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 <na...@gmail.com>wrote:
> 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" <na...@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
Posted by Nathan Quinlan <na...@gmail.com>.
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" <na...@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
Posted by Jamie Johnson <je...@gmail.com>.
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" <na...@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
Posted by Nathan Quinlan <na...@gmail.com>.
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
Posted by jej2003 <je...@gmail.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
From my somewhat limited testing, so far things look good...
Who can provide some more rigorous tests?
Re: mod_proxy_websocket
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Micha Lenk <mi...@lenk.info>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Micha Lenk <mi...@lenk.info>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ji...@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
Posted by Micha Lenk <mi...@lenk.info>.
Hi Jim,
Am 06.03.2013 18:22, schrieb Jim Jagielski:
> How does your module handle [the mod_reqtimeout] timeouts?
Still unanswered,,,
Regards,
Micha
Re: mod_proxy_websocket
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Mar 2013, at 10:54 PM, Stefan Fritsch <sf...@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
--
Re: mod_proxy_websocket
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 22, 2013, at 4:54 PM, Stefan Fritsch <sf...@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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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 <ji...@jagunet.com> wrote:
> > On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Perfect! Thx!
On Mar 23, 2013, at 12:15 PM, Nathan Quinlan <na...@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 <je...@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" <ji...@jagunet.com> wrote:
>>> This would be EXTREMELY easy just using ->notes
>>>
>>> On Mar 19, 2013, at 9:03 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>>>
>>>> On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Nathan Quinlan <na...@gmail.com>.
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 <je...@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" <ji...@jagunet.com> wrote:
>> This would be EXTREMELY easy just using ->notes
>>
>> On Mar 19, 2013, at 9:03 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>>
>>> On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <je...@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" <ji...@jagunet.com> wrote:
> This would be EXTREMELY easy just using ->notes
>
> On Mar 19, 2013, at 9:03 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> >
> > On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Jamie Johnson <je...@gmail.com>.
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" <ji...@jagunet.com> wrote:
> This would be EXTREMELY easy just using ->notes
>
> On Mar 19, 2013, at 9:03 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> >
> > On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Jim Jagielski <ji...@jaguNET.com>.
This would be EXTREMELY easy just using ->notes
On Mar 19, 2013, at 9:03 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 18, 2013, at 4:56 PM, Stefan Fritsch <sf...@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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by Micha Lenk <mi...@lenk.info>.
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