-
Notifications
You must be signed in to change notification settings - Fork 696
Return response when header validation fails #3346
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
base: main
Are you sure you want to change the base?
Conversation
self.sendResponseOnInvalidHeader = false | ||
} | ||
|
||
public init(sendResponseOnInvalidHeader: Bool) { |
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.
I wonder if we should create a configuration structure. That would let us extend this again in future without needing to provide more initializers and more pipeline builders.
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.
Happy to add that in. Would you envisage a config type with an initialiser that takes no arguments and each one can be set individually?
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.
Yeah, that seems sensible.
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.
Ok updated - I've only added the new configuration option to avoid an explosion of deprecations and confusing APIs. And I'm sure we need to refine the naming
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.
I think we should pass the new config field to this initializer.
Allow the
NIOHTTPResponseHeadersValidator
to be configured to return a response if the header validation fails. This allows something to be returned to client and can fix issues where proxies might mark a node as bad if aRST
is returned. This has to be done in the validator since all future writes are dropped so any error handler won't be able to catch the error and write out a fallback response.I haven't touched trailer validation, not sure if you want me to look at that. I don't know if an empty end would be valid as other data would have been already written to the channel.