You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Versions of relevant software used
grpcwebproxy-v0.15.0
What happened
We use WebSocket to connect browser-clients with bi-directional streaming and noticed that although some headers are listed in --allowed_headers, they were not forwarded to the server.
For example, we used to run grpcwebproxy with --allowed_headers=x-forwarded-for , but header X-Forwarded-For wasn't forwarded.
Versions of relevant software used
grpcwebproxy-v0.15.0
What happened
We use WebSocket to connect browser-clients with bi-directional streaming and noticed that although some headers are listed in
--allowed_headers
, they were not forwarded to the server.For example, we used to run grpcwebproxy with
--allowed_headers=x-forwarded-for
, but headerX-Forwarded-For
wasn't forwarded.We debugged it and found that grpcwebproxy filters WebSocket headers as case-sensitive.
To confirm the issue, we've ran grpcwebproxy with
--allowed_headers=x-forwarded-for,X-Forwarded-For
and it started to work.What you expected to happen
We would expect that grpcwebproxy will follow the RFC:
Moreover, for regular HTTP headers are handled as case-insensitive: 1 -> 2 -> 3, so we would expect a consistent behavior across all protocols.
How to reproduce it (as minimally and precisely as possible):
--use_websockets
and--allowed_headers=header_name
.Header_Name
.--allowed_headers=Header_Name
.Anything else we need to know
Please acknowledge the issue and we would be happy to fix it.
The text was updated successfully, but these errors were encountered: