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

Perfect-NIO should close the Channel if it receives an error in the last ChannelHandler #6

Closed
weissi opened this issue Feb 25, 2019 · 2 comments

Comments

@weissi
Copy link

weissi commented Feb 25, 2019

In SwiftNIO it's generally a good idea that on errorCaught, the Channel should be closed to prevent leaking network connections that are in some error states. In Perfect-NIO this should be added to NIOHTTPHandler. But this advice applies to any NIO ChannelPipeline: Generally the last handler (I usually call it the 'application handler') should close on unknown error.

Why? Generally, ChannelHandlers fire errors in cases where they don't know how to recover themselves. If another, later ChannelHandler knows how to recover, that ChannelHandler would consume the error. In other words: If an error reaches the end of the pipeline, nobody knew how to handle that error and closing the Channel is a good default.

This has always been true in SwiftNIO but in NIO 2 this will become especially important because ByteToMessageDecoders (and the HTTP decoders) won't close the connections themselves anymore. Why is that? If the decoders themselves close the connection, then there's no way for the user to opt out.

The code to implement this is very straightforward:

public func errorCaught(ctx: ChannelHandlerContext, error: Error) {
    switch error {
    case let e as SomeErrorTypeIKnowHowToHandle where e.someCondition == expectedValue:
        // handle error
    case let e as SomeOtherErrorIKnowHowToHandle:
        // handle that error
    default:
        // log error?
        ctx.close(promise: nil)
    }
}
@kjessup
Copy link
Member

kjessup commented Feb 25, 2019

OK, I think I need to figure out exactly what types of errors will pass through there, but the ctx.close is in there now, thank you!

@kjessup kjessup closed this as completed Feb 25, 2019
@weissi
Copy link
Author

weissi commented Feb 25, 2019

if you don't emit any, there really shouldn't be any non-fatal errors assuming you use the HTTPServerProtocolErrorHandler which you get with configureHTTPServerPipeline(..., withErrorHandling: true). I'd highly recommend using configureHTTPServerPipeline(..., withErrorHandling: true)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants