From b2bc717279bc00243d25f6c344666c8ef92bd736 Mon Sep 17 00:00:00 2001
From: Akshay Shah <akshay@akshayshah.org>
Date: Mon, 13 Feb 2023 11:32:25 -0800
Subject: [PATCH] web: make HTTP field names case-insensitive

I'm opening this PR to (hopefully!) stimulate a discussion. In brief,
I'd like to amend the gRPC-Web protocol docs to encourage clients to
follow standard HTTP semantics.

The gRPC-Web specification is a nicely-designed way for proxies to expose
standard HTTP/2 gRPC servers to clients using less tightly-controlled
HTTP stacks, such as web browsers. To serve that goal, it seems valuable
to have the gRPC-Web specification follow [RFC 9110 (HTTP
Semantics)](https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names).
Like previous RFCs, 9110 specifies that "field names are
case-insensitive." However, the current gRPC-Web specification requires
that servers and proxies "use lower-case header/trailer names" on the
wire. In principle, mandating casing on the wire is fine (if unusual);
however, it encourages clients to violate HTTP semantics and _depend_ on
the wire casing.

I'd like to loosen the gRPC-Web specification to permit any casing on
the wire, emphasizing that gRPC-Web clients ought to follow standard
HTTP semantics and treat field names case-insensitively. This amendment
does not affect the correctness of Envoy (which may continue to use
lower-case field names) or the `grpc-web` Javascript project (which
already treats field names case-insensitively, thanks to the Web
Platform's `Headers` interface). However, it does clarify that
`grpc-dart` is _incorrect_ in relying on lower-case field names.

Relates to https://github.com/improbable-eng/grpc-web/issues/228 and
https://github.com/bufbuild/connect-go/issues/453/
---
 doc/PROTOCOL-WEB.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/PROTOCOL-WEB.md b/doc/PROTOCOL-WEB.md
index c3f9169b331b1..99e473fef2304 100644
--- a/doc/PROTOCOL-WEB.md
+++ b/doc/PROTOCOL-WEB.md
@@ -48,7 +48,8 @@ Content-Type
 HTTP wire protocols
 
 1. support any HTTP/*, with no dependency on HTTP/2 specific framing
-2. use lower-case header/trailer names
+2. use any casing for header/trailer names (following HTTP semantics, clients
+   must treat header and trailer names case-insensitively)
 3. use EOF (end of body) to close the stream
 
 ---