[aida] WebSockets behind a proxy

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

Hi Phil,

Unfortunately no docs for Swazoo, on the website there was just one example.

I'm looking at the HTTPRequest>>readBodyFrom: and 8 byte read is only if 
contentLength header is missing in update request. Is that so with 
request from proxy? In this case it was expected that body of upgrade 
request is exactly 8 bytes long, which was a case when I worked on that. 
Is now different? How did you solve the problem, can you post a code?

Phil (list) je 17. 06. 2016 ob 11:15 napisal:
> Janko,
> On Fri, 2016-06-17 at 08:58 +0200, Janko Mivšek wrote:
>> 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
>> request while later over the same TCP/IP connection WebSocket
>> packets
>> starts flowing, possibly on both directions simultaneously (full
>> duplex).
> I actually have it working now, so it does work.  You are correct, you
> need to have a functioning reverse proxy as well as the wstunnel module
> or this will not work at all.  The problem was in a difference between
> the upgrade request sent by the browser and the one sent by Apache as
> they are slightly different (but not in a way that seems to matter to
> anything but Swazoo)...
>> 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.
> Wireshark was helpful in confirming that the proxy was sending requests
> that Aida was seeing but the problem was within Swazoo/Aida (i.e. it
> wasn't responding) so I had to crawl around the connection code a bit
> and insert a number of logging and halt statements to figure out what
> was going on internally.  (if there are any docs on Swazoo internals,
> they would be most welcome as it took me a bit of time to narrow it
> down mainly because I didn't know where to start looking initially.
>   Any available docs would be quite helpful should I need to dive into
> Swazoo internals for a future issue.)
> It turned out that the request #readBodyFrom: is forcing an 8-byte read
> (the framing header?) for WebSocket upgrade requests which both Chrome
> and Firefox appear to supply in their upgrade requests, but Apache does
> not when acting as the proxy server. There is even a comment in the
> #readBodyFrom: code indicating that this seemed strange so I'm not sure
> why it's there, but this read was causing the request to timeout
> waiting for data which never arrived.  Since it doesn't appear to be
> needed so I just commented it out and everything started working.  So
> far I haven't noticed any problems (i.e. WebSockets are now working
> both directly to Aida as well as via a proxy) but would be interested
> in knowing if there is something that I might have overlooked re: why
> that 8-byte read in #readBodyFrom: would be necessary?
> Thanks,
> Phil
> _______________________________________________
> Aida mailing list
> Aida na aidaweb.si
> http://lists.aidaweb.si/mailman/listinfo/aida

Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

More information about the Aida mailing list