-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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 max_message_size for websockets (both client and server) #1952
Comments
adding stream api is easy to add, problem is backward compatibility |
Any updates here? I think this feature is important. |
Nobody has worked on it yet. |
Hope to find time! |
Hmm.. Is this implemented within #3045 ? |
Yes. Closing the issue. |
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. |
Feature
Aiohttp has no limit on websocket message sizes. I had a brief discussion in the google-group about this and decided to create this issue.
That looks pretty dangerous, as it allows to DoS/OOM the server with a single client without any effort at all (you can implement this 'killer' client on a simple socket API without expending the memory yourself).
Closest 'conceptual' relative of aiohttp (IMHO) aka tornado has this limit both on client and on server APIs:
http://www.tornadoweb.org/en/stable/websocket.html#tornado.websocket.WebSocketHandler
http://www.tornadoweb.org/en/stable/websocket.html#tornado.websocket.WebSocketClientConnection
It cannot be implemented on the application layer - it's too late, message has been fully loaded already. This limit must be deep in protocol implementation, where websocket fragmented messages are collected.
ps. I understand that it can probably alleviated by using a production reverse proxy, but for pure WS workload direct connection seems reasonable too.
pps. I'm not sure if I'll be able to produce a PR on this anytime soon, but it seems to be important for production use of aio websockets (as is #1845, shameless plug xD. #1951 also looks scary.).
Possible implementation
Proposal: Add max_message_size parameter both to ClientSession.ws_connect and to WebSocketResponse, which will reject oversized messages right on the header parsing stage (and either close the connection or emit the WSMsgType.Error message). As a bonus, the same parameter can be added to the Application, that would serve as a default value for the WebSocketResponse one (if it's possible).
Another possible solution would be to expose some kind of streaming API. IMHO that would be more complicated both for the user and for the implementer, but it's would also work.
The text was updated successfully, but these errors were encountered: