forwarding binary metadata is broken

[kazegusuri]

gRPC can handle binary metadata with -bin suffix key. The value is encoded to base64 before sending metadata and decoded by receiver implicitly. grpc-gateway now forwards all metadata values as is. Non-ASCII values are dropped as a result.

Is there a right way to handle binary header value in HTTP/1.1? Or how about just encoding binary metadata to base64? Once determined I will fix the code with pleasure :)

[tmc]

I know this is super old but yes base64 encoding seems like a fine path.

[vaijab]

I have been fiddling with this myself. There is no easy way to send bytes in a header value with curl (for example) over HTTP/1.1. Normally this would be base64 encoded, which is what happens in HTTP/2 transport implicitly.

For example, let's consider an HTTP/1.1 header called grpc-metadata-foo-bin. When grpc-gateway receives an HTTP/1.1 request with mentioned header, it will strip grpc-metadata- prefix and will pass the header to gRPC call via gRPC metadata.

gRPC HTTP/2 transport layer will base64 encode header (named with -bin suffix) value before putting it on the wire, same happens on the other end - the value gets decoded.

So here is the catch, if you simply do curl -H 'grpc-metadata-foo-bin: <base64-encoded-value>', gRPC transport layer will just base64 encode the value again, which is not what we wanted to see.

I think, that grpc-gateway should be a little smarter when it comes to headers names with -bin suffix. What the gateway should do is to expect -bin header value to be base64 encoded and decode it before making a gRPC call.

Thoughts?