Skip to content
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

Made websocket subprotocols conform to spec #181

Merged
merged 3 commits into from
Nov 28, 2014

Conversation

flying-sheep
Copy link
Contributor

fixes #178

@asvetlov
Copy link
Member

Hmm.
I doubt that protocol mismatch should produce UserWarning.
But we definitely need some indication.
Maybe just protocol is None check for do_handshake() return value is enough?

@flying-sheep
Copy link
Contributor Author

why do you think a warning is unsuited here?

something wants to connect with a protocol that isn’t supported: that’s not normal, and a log entry might help debugging instead of silently succeeding with a return value that might not be checked.

@asvetlov
Copy link
Member

Warnings mean something's wrong with your code that won't get better by ignoring it, and you should fix it at some point.

I see nothing wrong with my code if client requests non-supported protocol. Server code should not changed to "fix" warning, problem is inside incompatible client.
The issue may be solved by proper logging, not warnings.warn().

@ludovic-gasc
Copy link
Contributor

I'm agree with @asvetlov
For me, you can use warnings python module when you make a Python library and you want to alert developers if you break the API for the next version.

In this case, I strongly vote to use a logger with warning level.
For the daemons I made, I use this logging configuration: https://github.com/Eyepea/API-Hour/blob/master/examples/project_template/%7B%7Bcookiecutter.app_name%7D%7D/etc/%7B%7Bcookiecutter.app_name%7D%7D/logging.ini

If you use warnings instead of logging for that, I don't receive e-mail that something is wrong with a client.

@flying-sheep
Copy link
Contributor Author

it’s up to him then to introduce logging, and this will wait?

@asvetlov
Copy link
Member

it’s up to him then to introduce logging, and this will wait?

@flying-sheep sorry, I don't follow.

@flying-sheep
Copy link
Contributor Author

I meant: this project doesn’t use any logging yet AFAICT. So you should introduce logging how you see fit (central logger with just basicConfig() or per-module logger, maybe even finer grained. using name, hardcoded names or custom logger classes, yadda yadda)

and after i see how you want logging to be done, i’ll update this pull request to use logging.

@ludovic-gasc
Copy link
Contributor

Do you talk about this: https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/log.py ?
If yes, you could add a logger for websockets.

@asvetlov
Copy link
Member

Yes, I think ./aiohttp/log.py is good place for new logger. You can call it "aiohttp.websocket" for example.

@flying-sheep
Copy link
Contributor Author

it appears that i am blind or looked at an old version or something.

in any case, i didn’t know of the existence of log.py in this project, so it’s clear why you’re confused by my wrong-assumption-fueled comments -.-

@flying-sheep flying-sheep force-pushed the websocket-error-response branch 2 times, most recently from 0edbf5d to 98a5e16 Compare November 28, 2014 12:22
@flying-sheep
Copy link
Contributor Author

done!

asvetlov added a commit that referenced this pull request Nov 28, 2014
Made websocket subprotocols conform to spec
@asvetlov asvetlov merged commit b8548c7 into aio-libs:master Nov 28, 2014
@asvetlov
Copy link
Member

Thanks!

@flying-sheep flying-sheep deleted the websocket-error-response branch March 13, 2015 16:03
@lock
Copy link

lock bot commented Oct 30, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 30, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Return no protocol instead of erroring when not agreeing on a protocol
4 participants