uhv: define extensible validation API

[ameily]

As part of the unified header validation component, Envoy will need to define an extensible API. The tech spec describes a simple API that will be initially implemented.

class HeaderValidator {
 enum class HeaderEntryValidationResult { Accept, Reject };
 
 virtual HeaderEntryValidationResult validateHeaderEntry(
                    const HeaderEntry& entry) PURE;
 
 // validateRequestHeaderMap performs URI path normalization and may redirect
 // request to the new URI path
 enum class RequestHeaderMapValidationResult { Accept, Reject, Redirect };
 
 virtual RequestHeaderMapValidationResult validateRequestHeaderMap(
                    RequestHeaderMap& header_map) PURE;

 enum class ResponseHeaderMapValidationResult { Accept, Reject };
 virtual ResponseHeaderMapValidationResult validateResponseHeaderMap(
                    ResponseHeaderMap& header_map) PURE;
};

class HeaderValidatorFactory : public Config::TypedFactory {
 enum class Protocol { HTTP09, HTTP1, HTTP2, HTTP3 };
 virtual std::shared_ptr<HeaderValidator> createHeaderValidator(
                    Protocol protocol) const PURE;
};

The goal of this issue is to define the API, get feedback from the team and community, document the API, and potentially create factory stubs for the support HTTP codecs.

[ameily]

@yanavlasov Would it make sense to include a boolean flag for requests that differentiates between downstream (client-originated) and upstream requests? I could see it being useful in custom implementations to have a different behavior for upstream requests, although I don't think it would be used by the Envoy-maintained UHV implementation.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[yanavlasov]

@yanavlasov Would it make sense to include a boolean flag for requests that differentiates between downstream (client-originated) and upstream requests? I could see it being useful in custom implementations to have a different behavior for upstream requests, although I don't think it would be used by the Envoy-maintained UHV implementation.

This is covered by having two different methods validateRequestHeaderMap and validateResponseHeaderMap. Separate methods are needed since the C++ type of request and response header maps is different.

[ameily]

This is being discussed in PR #21172

[ameily]

This has been merged.