Reading WebSocket incoming messages and responses?

[IvesAwadi]

Thank you for the library, it's amazing so far but for some reason I can't figure out how to log incoming data from the WebSocket and also read its responses.

[WSH032]

Hi @IvesAwadi.

Considering that WebSocket is more complex than HTTP, I didn't design this feature at the time.

I wanted to implement this feature, but I lacked feedback from the community, so I was hesitant about the API design. Can you describe how you would like to use this feature with code? A Feature request is welcome!

[IvesAwadi]

Hmm, if an exception occurs, it should create an error message and send that back to the client. The error message + code should be fine. Also, is there possibly of using (try, catch) to handle the exceptions?

[WSH032]

I'm a bit hesitant to introduce such a complex feature. The initial purpose of developing this library was to implement a proxy server that is as transparent as possible, but allowing the proxy to modify everything at will seems to go against this idea.

The idea behind this library is somewhat stubborn, although I still believe it is necessary to give the proxy server minimal modification capabilities, such as proxy authentication.

However, I don't quite agree with the proxy server being able to modify everything at will. My reasoning is: if such a high level of control is needed, it essentially ceases to be a proxy server. In that case, why not manually establish a connection between the target server and the client, and handle message passing yourself?

I currently prefer the second API because it retains minimal modification capabilities. But these are all things that can be further discussed. Can you give me some specific use cases or try to convince me?

[IvesAwadi]

I understand the concerns, I personally believe having more control over the proxy is the way to go for a WebSocket. I say this because the proxy should allow/intercept what it's being sent because it sits in the middle of both connections, and for Realtime communications like web sockets can be used for, it needs this functionality to modify data on the fly if needed, not just authentication.

I can use the second api for my use case if it's too complex to add the first one, I do not want to alter what the library was meant for just for me.

[WSH032]

Can you give me some time? A few days or until the weekend? Implementing the first API might require changing some underlying implementations. If we hastily introduce the second API, due to backward compatibility reasons, it might not be possible to implement the first API in the future.

[IvesAwadi]

Yes, take all the time you need. I'll be closely following this project.