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

Add max_message_size for websockets (both client and server) #1952

Closed
alexmnazarenko opened this issue Jun 5, 2017 · 7 comments
Closed

Add max_message_size for websockets (both client and server) #1952

alexmnazarenko opened this issue Jun 5, 2017 · 7 comments
Labels

Comments

@alexmnazarenko
Copy link

alexmnazarenko commented Jun 5, 2017

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.

@fafhrd91
Copy link
Member

fafhrd91 commented Jun 5, 2017

adding stream api is easy to add, problem is backward compatibility

@asvetlov asvetlov added the good first issue Good for newcomers label Apr 25, 2018
@decaz
Copy link
Contributor

decaz commented May 10, 2018

Any updates here? I think this feature is important.

@asvetlov
Copy link
Member

Nobody has worked on it yet.
@decaz would you be a champion?

@decaz
Copy link
Contributor

decaz commented May 10, 2018

Hope to find time!

@decaz
Copy link
Contributor

decaz commented Jun 1, 2018

Hmm.. Is this implemented within #3045 ?

@asvetlov
Copy link
Member

asvetlov commented Jun 1, 2018

Yes. Closing the issue.

@lock
Copy link

lock bot commented Oct 28, 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].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new

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

No branches or pull requests

4 participants