Return response when header validation fails

[0xTim]

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 a RST 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.

[Lukasa]

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.

[0xTim]

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?

[Lukasa]

Yeah, that seems sensible.

[0xTim]

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

[Lukasa]

I think we should pass the new config field to this initializer.

[0xTim]

Ok updated!

[0xTim]

Actually in hindsight I disagree with this partially - in Vapor we'll be setting up the validator ourselves so will need to set up a pipeline configuration option just to create this. Should we offer both APIs?

[Lukasa]

Hmm, perhaps I'm not following where the issue is there. Can you clarify?

[0xTim]

So in Vapor when we construct our pipeline, we just create the handlers ourselves rather than using NIO's helpers - https://github.com/vapor/vapor/blob/main/Sources/Vapor/HTTP/Server/HTTPServer.swift#L605.

If the validator was to take a ChannelPipeline.SynchronousOperations.Configuration type, we'd need to construct the entire configuration object when we just want to be able to set the options for that specific handler directly. This might cause confusion if we created a configuration type that then wasn't used for another handler which would be misconfigured even though a dev would be setting the configuration object. So IMO it makes sense to have a configuration object for configureHTTPServerPipeline, but each handler should be able to be set up independent of that if desired - does that make sense?

[Lukasa]

Oh sorry, I was suggesting a configuration object only for this handler. That would then replace the mystery-meat boolean in the configureHTTPServerPipeline.