if the goal of HyBi / IETF 6455 was to keep communication simple, it failed

[goofyseeker311]

if the websocket message event.data on the html javascript client side is not clear text, but some random blob variable, hard to use, then whats the point of not keeping it as plain text.

how do I get plain text from the message event data blob? event.data.text() gives just promise, not the payload text.
browsing through the message blob in browser dev mode does not give any reasonable answer.

when connecting to the same plain text socket with putty, it gives two clear lines of text data instead.
websocket on the javascript size says sizes 125 and 57 for a couple messages, which are reasonable for the actual text lengths.

[goofyseeker311]

all the irc protocol of the origin server is (should be) plain text always. all data of course should be binary, even the plain text.

[CendioOssman]

websockify is a WebSocket to TCP proxy. Since TCP is a binary protocol, not a text one, it is natural for websockify to present things as binary on the WebSocket side as well. websockify doesn't know what application protocol is used, so it doesn't know how to decode the TCP data to text.

Like TCP, we expect the application layer (the JavaScript) to do the encoding/decoding. I would suggest looking at something like the TextEncoder:

https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder

[goofyseeker311]

filereader converts the blob to text, like the irc protocol is. I would have expected strings of binary.

edit: another question is, why are messages not being delivered? if stuff goes through cloudflare, then some reply messages are passed through apache, but if local network wss access then only connection is opened and its closed with no reply messages, from the actual irc server.

current apache proxy config for http/s is:

RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /wsirc ws://localhost:6668/ [P,L]
ProxyPass /wsirc http://localhost:6668/
ProxyPassReverse /wsirc http://localhost:6668/

and websocket javascript points to wss:/localhost/wsirc.
websockify is plain websocket at 6668, to localhost:6667.

does websockets require full wss chain if wss at all.
now it converts to unsecure ws on the second part.

[CendioOssman]

You should have as many hops as you'd like. Please open a new issue with the details of your setup, and the packets you see and don't see. It's also helpful if you can do some basic checks with tcpdump that the traffic is flowing through all hops.

[goofyseeker311]

I dont know if its websockify specifically.

well, an unrealircd server does to reply with all the response messages in all cases, or at all.
an initial websocket connect open (through websockify) is always happening. communication is not necessarily happening.

if used through cloudflare, then first irc protoc reply messages are happening.
if used through local network (192.168...) then no reply irc protocol messages not happening.

edit: direct terminal connection to the ircd server always responds like it should.
ie: server starts with two lines of server connection status. with local connection none of these appears.
nick guest\n user guest guest guest : guest. (server responds ping :12345 expects pong :12345).

[goofyseeker311]

somehow if you dont immediately send stuff during socket.onopen = function(event) {} then even the local server over https reply messages appear. otherwise it will immediately close the connection.

[goofyseeker311]

so instead of the websockify accepting a plain text message (it disconnects the ircd server connection), how are you supposed to convert a text to a websockify compatible blob?

example javascript websocket code for websockify, both receive and send, would be excellent. especially the blob version, as the text only event.data stuff generic examples will not work.

in the test subfolder of this project, it seems like TextEncoder() and TextDecoder() are used to transform the messages to the required format.

edit: using text encoder/decoder gives error: Failed to execute 'decode' on 'TextDecoder': parameter 1 is not of type 'ArrayBuffer'. so the text decoder/encoder does not like blob, which websockify server is currently giving back to the browser.

Using Uint8Array(event.data) or Uint32Array(event.data) instead does not directly give any benefits.

edit: sending blobs (type '' and 'text/plain', websockify sends a type: '' blob message back from the origina server) to the websockify/origin server does not change anything.

edit2: someone suggested on internet that the wss: encrypted connection would be still encrypted when passing to ws: in websockify. idk if that is reasonable to assume so, because the socket can read back to the web browser, just not receiving on the origin local server side, on the ircd server. I think its only the data format that websockify expects to be able to forward to a real tcp socket connection.

edit3: ok forgot to send the binary blob, which includes the string message. that works now.

[goofyseeker311]

so how about outgoing connections ssl from websockify, not the web browser to apache wss or even the apache to websockify wss.

ie if you want to mirror the websockify socket off the server.

currently the websockify application log says: "handler exception: [Errno 107] Transport endpoint is not connected" when trying to point to an SSL ircd server socket. that socket works fine for normal SSL irc client.

I guess --ssl-target will handle that.

edit: yep --ssl-target works.