-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add support for automatic HTTP error reporting. #268
Conversation
265104a
to
3f06fc1
Compare
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.
that's great, thank you!
CC'ing @tanner0101 because they probably want to use the |
3f06fc1
to
2b70cb4
Compare
@Lukasa hmm, this hit
looks like we have a race in that test, this shouldn't be related to your changes AFAIK |
@swift-nio-bot test this please |
2b70cb4
to
48e833f
Compare
Motivation: Currently the HTTP decoders can throw errors, but they will be ignored and lead to a simple EOF. That's not ideal: in most cases we should make a best-effort attempt to send a 4XX error code before we shut the client down. Modifications: Provided a new ChannelHandler that generates 400 errors when the HTTP decoder fails. Added a flag to automatically add that handler to the channel pipeline. Added the handler to the HTTP sample server. Enabled integration test 12. Result: Easier error handling for HTTP servers.
48e833f
to
bc7e1c8
Compare
let headers = HTTPHeaders([("Connection", "close"), ("Content-Length", "0")]) | ||
let head = HTTPResponseHead(version: .init(major: 1, minor: 1), status: .badRequest, headers: headers) | ||
ctx.write(self.wrapOutboundOut(.head(head)), promise: nil) | ||
ctx.writeAndFlush(self.wrapOutboundOut(.end(nil)), promise: nil) |
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.
@Lukasa should we also attach a callback to the future which closes the channel once written ?
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.
No. Any of these errors will cause a channel to be closed by the HTTPDecoder, so I don't think it's required.
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.
Just a suggestion
// A side note here: we cannot block or do any delayed work. ByteToMessageDecoder is going | ||
// to come along and close the channel right after we return from this function. | ||
let headers = HTTPHeaders([("Connection", "close"), ("Content-Length", "0")]) | ||
let head = HTTPResponseHead(version: .init(major: 1, minor: 1), status: .badRequest, headers: headers) |
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.
is 1 .1 a good choice here or should we use 1.0 ?
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.
What value do we obtain by using 1.0?
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.
Was just wondering if 1.0 would be a better choice but I guess 1.1 is more used these days so all good
@swift-nio-bot test this please |
@Lukasa @weissi leak detector tripped
@swift-nio-bot test this please |
@normanmaurer Please re-review. |
@Lukasa thanks! |
Motivation:
Currently the HTTP decoders can throw errors, but they will be ignored
and lead to a simple EOF. That's not ideal: in most cases we should make
a best-effort attempt to send a 4XX error code before we shut the client
down.
Modifications:
Provided a new ChannelHandler that generates 400 errors when the HTTP
decoder fails.
Added a flag to automatically add that handler to the channel pipeline.
Added the handler to the HTTP sample server.
Enabled integration test 12.
Result:
Easier error handling for HTTP servers.