-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add user-set additional headers for handshake #155
Comments
I don't really understand what you mean here. The way I'm thinking about this, the headers are read prior to upgrading a connection to a websocket connection. While the websocket is open, any further communication on that connection will be interpreted as websocket communication. So I suppose you actually mean 'have the ability of adding additional headers in the opening handshake'. I think you have that option. I might be wrong. Do you have a halfway-working example? |
Sorry for my poor english. But yes, that's what I mean: have the ability of adding additional headers in the opening handshake. |
Yes, adding this header could 'easily' be achieved by adding additional headers through the function call. But it complicates the API. For the user to be aware of which headers is missing requires detail knowledge, or at least a decent ability to study error messages. How did error messages look in your case? I hope they were informative. Personally I think writing a custom 'open' function has more appeal than studying the nitty gritty of keyword arguments. It could be something like this:
|
Some websocket server may check the headers, such as the example of
golang.org/x/net/websocket
.Get 403 when there is no "Origin: xxx" header.
For compatibility, it shoud have the ability of adding additional headers to open websocket.
The text was updated successfully, but these errors were encountered: