-
Notifications
You must be signed in to change notification settings - Fork 656
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
Allow to specify the max websockets frame size when using the upgrader. #315
Changes from 2 commits
97d0cd0
aee563f
b686693
b9036b0
d679b0b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,6 +59,7 @@ public final class WebSocketUpgrader: HTTPProtocolUpgrader { | |
|
||
private let shouldUpgrade: (HTTPRequestHead) -> HTTPHeaders? | ||
private let upgradePipelineHandler: (Channel, HTTPRequestHead) -> EventLoopFuture<Void> | ||
private let maxFrameSize: Int | ||
|
||
/// Create a new `WebSocketUpgrader`. | ||
/// | ||
|
@@ -73,10 +74,21 @@ public final class WebSocketUpgrader: HTTPProtocolUpgrader { | |
/// websocket protocol. This only needs to add the user handlers: the | ||
/// `WebSocketFrameEncoder` and `WebSocketFrameDecoder` will have been added to the | ||
/// pipeline automatically. | ||
/// - maxFrameSize: The maximum frame size the decoder is willing to tolerate from the | ||
/// remote peer. WebSockets in principle allows frame sizes up to `2**64` bytes, but | ||
/// this is an objectively unreasonable maximum value (on AMD64 systems it is not | ||
/// possible to even allocate a buffer large enough to handle this size), so we | ||
/// set a lower one. The default value is the same as the default HTTP/2 max frame | ||
/// size, `2**14` bytes. Users may override this to any value up to `UInt32.max`. | ||
/// Users are strongly encouraged not to increase this value unless they absolutely | ||
/// must, as the decoder will not produce partial frames, meaning that it will hold | ||
/// on to data until the *entire* body is received. | ||
public init(shouldUpgrade: @escaping (HTTPRequestHead) -> HTTPHeaders?, | ||
upgradePipelineHandler: @escaping (Channel, HTTPRequestHead) -> EventLoopFuture<Void>) { | ||
upgradePipelineHandler: @escaping (Channel, HTTPRequestHead) -> EventLoopFuture<Void>, maxFrameSize: Int = 1 << 14) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can I recommend that instead of making this change you just add a new constructor that this one calls, with |
||
precondition(maxFrameSize <= UInt32.max, "invalid overlarge max frame size") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if you're already preconditioning here, mind checking it's positive too? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there any point in this precondition? I think it just duplicates logic that exists in the web socket frame decoder. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Lukasa imho its better to fail fast... WDYT ? |
||
self.shouldUpgrade = shouldUpgrade | ||
self.upgradePipelineHandler = upgradePipelineHandler | ||
self.maxFrameSize = maxFrameSize | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Curious, what is the motivation for providing two public constructors rather than a constructor with the default value? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vlm Short answer is "to preserve the trailing closure". |
||
|
||
public func buildUpgradeResponse(upgradeRequest: HTTPRequestHead, initialResponseHeaders: HTTPHeaders) throws -> HTTPHeaders { | ||
|
@@ -111,7 +123,7 @@ public final class WebSocketUpgrader: HTTPProtocolUpgrader { | |
|
||
public func upgrade(ctx: ChannelHandlerContext, upgradeRequest: HTTPRequestHead) -> EventLoopFuture<Void> { | ||
return ctx.pipeline.add(handler: WebSocketFrameEncoder()).then { | ||
ctx.pipeline.add(handler: WebSocketFrameDecoder()) | ||
ctx.pipeline.add(handler: WebSocketFrameDecoder(maxFrameSize: self.maxFrameSize)) | ||
}.then { | ||
self.upgradePipelineHandler(ctx.channel, upgradeRequest) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can also keep this internal if we like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my vote would go to let's keep it internal :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I think we should keep it internal too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's always easier to make things more public than to make them less public.