Support HTTP extension (custom) methods

[yanavlasov]

Presently H/1 codec has a hardcoded list of HTTP methods it accepts. This prevents applications that use extension methods (see RFC) from working.

[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.

[bencebeky]

The current HTTP/1 parser is http-parser, which cannot be configured to accept custom methods. There is ongoing effort tracked at #21245 to migrate to Balsa as HTTP/1 parser. This can allow custom methods. When UHV is enabled, it will allow users to configure whether custom methods should be rejected via the restrict_http_methods field at

envoy/api/envoy/extensions/http/header_validators/envoy_default/v3/header_validator.proto

Lines 139 to 142 in 140dd10

	// Restrict HTTP methods to these defined in the `RFC 7231 section 4.1 <https://datatracker.ietf.org/doc/html/rfc7231#section-4.1>`_
	// Envoy will respond with 400 to requests with disallowed methods.
	// By default methods with arbitrary names are accepted.
	bool restrict_http_methods = 3;

.

[bencebeky]

The header validation logic in UHV already supports custom methods:

envoy/source/extensions/http/header_validators/envoy_default/header_validator.cc

Lines 99 to 106 in 2970ddb

	if (config_.restrict_http_methods()) {
	is_valid = kHttpMethodRegistry.contains(method);
	} else {
	is_valid = !method.empty();
	for (auto iter = method.begin(); iter != method.end() && is_valid; ++iter) {
	is_valid &= testCharInTable(kMethodHeaderCharTable, *iter);
	}
	}

However, BalsaParser currently does not skip comparison of method to the hardcoded list regardless of how UHV is configured:

envoy/source/common/http/http1/balsa_parser.cc

Lines 44 to 45 in 2970ddb

	// TODO(#21245): Skip method validation altogether when UHV method validation is
	// enabled.

[vamshi177]

Hi,
Recently, we had a use case requiring support for custom methods in our environments. However, using http_protocol_options.allow_custom_methods didn't fully resolve the issue, as the calls were being rejected by the client Envoy at the http_inspector, which still uses http_parser and doesn't currently support custom methods.

I'm working on a change to enable custom methods in http_parser. Could you please review this change Thank you!