Grpc-Metadata- functionality not matching documentation

[hoffin]

Mapping of HTTP request headers doesn't work as described in the documentation.

Remaining HTTP header keys are prefixed with Grpc-Metadata- and added with their values to gRPC request header

The Documentation asserts that all remaining headers will have Grpc-Metadata- prepended and be available to the gprc endpoint but in fact it only passes through headers that arrive with Grpc-Metadata- prepended already.

I'm looking to add the REST service behind kong API which has fixed headers added to the upstream call which I would like to access at the grpc endpoint. Options.

Options are..

• Make change to code to make it work as described.
• Change documentation to reflect actual working (such as)

Remaining HTTP header keys that are prefixed with Grpc-Metadata- will be added with their values to gRPC request header

Happy to do either but as I'm new to this project I've not managed to go through all the prior thinking.

[philipithomas]

You're correct. I added the incorrect documentation as I was getting up and running with the project, but this week I realized that it was incorrect. I think the fix is updating documentation, and your change looks good. I would just perhaps add that "all HTTP headers not prefixed with Grpc-Metadataare dropped."

However - I think there could be some possible security implications with this behavior. It means that an attacker can selectively inject gRPC metadata with a correctly-crafted request. Depending on how metadata is used, I think this could be scary.

[hoffin]

Right-o. Is there a know tricks in getting a non Grpc-Metadata- request headers into the gRPC endpoint within the reverse proxy code without manipulating the headers before it arrives, as these headers are not always available to be set at source.

Just to ask, is there a specific reason why it wasn't implemented in the way it was described in the documentation as that would solve my issue without having to manipulate the headers before they arrive at the reverse proxy?

[philipithomas]

The documentation was written after implementation. However, I think that the documented behavior is more secure than the actual one :-) @yugui - what are your thoughts?

[hoffin]

I would much prefer the documented method. There's a lot less fiddling to get access to the header data and much simpler integration with api gateways.

[tmc]

see #213 for some related discussion

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.