[aida] WebSockets behind a proxy

Janko Mivšek janko.mivsek at eranova.si
Fri Jun 17 08:58:18 CEST 2016


Hi Phil,

I think Apache reverse proxy should support WebSockets explicitly, 
otherwise this won't go. AFAIK this proxy store and forward HTTP 
requests and responses. WebSocket Update request is still a normal HTTP 
request while later over the same TCP/IP connection WebSocket packets 
starts flowing, possibly on both directions simultaneously (full duplex).

To better see what is happening use the Wireshark packet sniffer and 
look at the low level details, what the proxy is sending and what is 
returned by Swazoo.

Also temporary switch off all exception catching in Swazoo. AFAIK it 
could be in many places. Maybe some error happens inside Swazoo but it 
is ignored, that is, it just close the connection immediately. .

Hope this helps a bit
Janko

Phil (list) je 15. 06. 2016 ob 23:05 napisal:
> I needed to look a little further down the stack trace: it looks like
> the WebSocket upgrade request coming from Apache doesn't have the 8-
> byte body being expected by HTTPGet>>readBodyFrom: which is causing
> things to hang up.  So the good news is it is being recognized as a
> WebSocket request, the bad news is it isn't in the form expected.
>
> On Wed, 2016-06-15 at 07:06 -0400, Phil (list) wrote:
>> So I've done some more investigating and I think what's going on is
>> that the client is opening up the WebSocket with Apache, and Apache
>> in
>> turn is attempting to open up a WebSocket with Aida.  It looks like
>> it
>> is this second hop that is having the problem.
>>
>> If I'm following what's going on correctly it appears that by the
>> time
>> the request times out the SwazooBuffer has the correct request header
>> (i.e. the host name matches what I'd expect to see from the proxy
>> server and it is a connection upgrade request) in its read buffer
>> (i.e.
>> its internal collection ivar) but when I attempt to #fillBuffer I
>> still
>> get a StreamNoDataError: No data available. Socket probably closed.
>>
>> I'm thinking (more accurately at this point: guessing) perhaps the
>> request is arriving in an unexpected manner from Apache? i.e. because
>> it's effectively relaying the request in a less direct way than it
>> does
>> with non-WebSocket requests there might be a small delay between the
>> request starting and the header data actually becoming available that
>> is causing Swazoo some problems?  Note that only WebSockets are
>> having
>> this problem, everything else in Aida is working fine behind the
>> Apache
>> proxy.
>>
>> On a related note: unfortunately, the Swazoo website appears to be
>> gone
>> so any docs on its internals are no longer available.  Is there
>> anything (docs, diagrams, mailing list archives) that you might have
>> copies of that you could post on the Aida site that might be helpful
>> in
>> working through this?
>>
>> Thanks,
>> Phil
>>
>> On Tue, 2016-05-31 at 11:34 +0200, Janko Mivšek wrote:
>>> Phil (list) je 25. 05. 2016 ob 22:29 napisal:
>>>
>>>> I was taking a look at using WebSockets for an application but it
>>>> appears that Aida/Swazoo doesn't know how to deal with WebSockets
>>>> from
>>>> behind a proxy without a bit of work (i.e. where the connection
>>>> has
>>>> been pre-upgraded by Apache.)  I was wondering if there are any
>>>> pointers as to how to best handle this scenario?
>>>
>>> It is supposed that a proxy server deals with proxying WebSocket
>>> requests, AFAIK. So far my real-time apps are on intranets, so I
>>> didn't
>>> yet have this case to know more about.
>>>
>>> Best regards
>>> Janko


More information about the Aida mailing list