Fixes subprotocol selection (aling with rfc6455) #823
Conversation
|
Just received a notification from github with a comment from @FZambia.... But can not see it here.... |
|
O okay! Everything is clear now? |
|
As for me I still think that the RFC is not very clear about exact precedence, but seems there are some implementations which prefer client order already. The change in this PR may break some code I suppose - so probably it should be optional/configurable. But I am not a maintainer of this lib - just following. |
|
Well, I agree with you that it is not so clearly specified, but yeah, some other server implementations, that I know prefer the client's subprotocol in order of precedence. And that makes sense. Because in other cases - the server will always use its first one, and if the client knows that the server supports a few, it has to send only one it is interested in most... a bit weird... The tests are passing :) that is good. So I hope it won't break anything (much). |
|
Any maintainers around here? |
|
I agree that subprotocol selection should use the client order. Given the possibility that the PR breaks something, the PR will need to wait for a new maintainer. |
|
@KSDaemon I would like to see a unit test verifying that the order of the client protocols is preferred, then I think this would be good to be merged. |
|
@coreydaley Sure! I'll have a look! |
|
@coreydaley I've added tests. Please have a look when you'll have time! |
|
@coreydaley gentle ping |
|
Heh... yesterday was 1 year since I opened not the issue but PR with the fix! And it is still not merged.... And there is no indication that it will be merged in the foreseeable future.... |
|
@coreydaley gentle ping |
|
Yahoo! @coreydaley let's merge then? I can not make it :) |
|
Thank you! |
Fixes #822
Summary of Changes