Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Reading WebSocket incoming messages and responses? #39

Unanswered
IvesAwadi asked this question in Q&A
Discussion options

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.

You must be logged in to vote

Replies: 1 comment 9 replies

Comment options

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!

You must be logged in to vote
9 replies
Comment options

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?

Comment options

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?

Comment options

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.

Comment options

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.

Comment options

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants

AltStyle によって変換されたページ (->オリジナル) /