tree 5be5e2df5cf91618ddb7946671389420545d9404
parent 7c6f53ab79846decde5e624bb6fa5f7a1f8a922c
author Eric Anderson <ejona@google.com> 1631557819 -0700
committer GitHub <noreply@github.com> 1631557819 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJhP5i7CRBK7hj4Ov3rIwAAm94IAB+03J0d8/mhtbd/w5MZV9s8
 eeuBV/RV4rtQIFqrAME5s6NNLcv3VpG2EsSQCNs3BFv6XQitW9y3kHqWAlLuYonO
 FOMLU1qFnbejcT8ldp73SDRHDja7lgW9sK8qj7tgPsaz5X2nNgimXKQZPPI5jIxy
 tNJiBIF+AtfW13PauWTSeP2ejvhVf0bvII8hRHU6cNg950lx4kWHibLJ4VZnSYlY
 H1yUnfpbpWeY/1QzqRE31MOJ+rqAGKwBuTPvxf2hbHHGbh9aybtcoWKd5NBsAeRH
 MdSa9wJX21Mngv9dV10od9U5G3UObVfjON6tA3KIaDsd4sEaaJ7chwQR+rgJlo4=
 =Qxr7
 -----END PGP SIGNATURE-----
 

netty: Requests with Connection header are malformed

Although this is part of HTTP/2 and should have already been handled
already, it was noticed as part of RBAC work to avoid matching
hop-by-hop headers. See gRFC A41.

Also add a warning if creating Metadata.Key for "Connection". Use this
to try to help diagnose a client if it happens to blindly copy headers
from HTTP/1, as PROTOCOL_ERROR is hard to debug.