Transfer-Encoding value is case-insensitive by RFC.

[veshij]

Envoy rejects requests having "Transfer-Encoding: Chunked" with unsupported transfer encoding error.

Per RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing transfer-coding names are case-insensitive:

All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and
Transfer-Encoding (Section 3.3.1) header

Expected behavior: all transfer-encoding comparisons are case-insensitive.

Logs:

D0213 02:23:06.031513 33976 http [external/envoy/source/common/http/conn_manager_impl.cc:278] [C516843051] dispatch error: http/1.1 protocol error: unsupported transfer encoding

[veshij]

I can try to take a look how to fix that.

[mattklein123]

Trivial fix here:

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

Lines 582 to 592 in be10519

	if (current_headers.TransferEncoding()) {
	absl::string_view encoding = current_headers.TransferEncoding()->value().getStringView();
	if (Runtime::runtimeFeatureEnabled(
	"envoy.reloadable_features.reject_unsupported_transfer_encodings") &&
	encoding != Headers::get().TransferEncodingValues.Identity &&
	encoding != Headers::get().TransferEncodingValues.Chunked) {
	error_code_ = Http::Code::NotImplemented;
	sendProtocolError();
	throw CodecProtocolException("http/1.1 protocol error: unsupported transfer encoding");
	}
	}

[veshij]

@mattklein123 should we normalize transfer-encoding while parsing headers - otherwise it's possible to hit the same issue in other codepaths?

[mattklein123]

We haven't normalized header values so far to my knowledge. I'm not sure if it's worth it but I could go either way. @alyssawilk any thoughts?