Clarification about return Access-Control-Allow-Origin header

[arturgaleno]

🐛 Bug Report

I am new at gRPC ecosystem, and I am returning Access-Control-Allow-Origin from the gRPC server as Metadata. But after translate the gRPC response to HTTP response using grpc-gateway, my header becomes Grpc-Metadata-Access-Control-Allow-Origin.

To Reproduce

1. Return the header as response metadata.
2. Check if the response metadata is correct.
3. Call the equivalent REST request through grpc-gateway.

Expected behavior

Do not append the Grpc-Metadata prefix.

Actual Behavior

The grpc server returns the metadata correctly:

/gateway # grpc_cli call app:50051 FindById "id: 1" --protofiles=app.proto
connecting to app:50051
Received initial metadata from server:
access-control-allow-origin : *
age: 0
id: 1
title: "Hello"
status: 10

Rpc succeeded with OK status

But the Grpc-Metadata prefix is apended to the http response header:

Your Environment

GRPC_GATEWAY_VERSION=2.0.0

[johanbrandhorst]

Yeah this is the default behaviour for metadata headers returned from the gRPC server. The idea is that the gRPC server should be agnostic to it being exposed as a HTTP server via the gateway.

You can set these headers in the gateway instead using the forward response writer configuration: https://grpc-ecosystem.github.io/grpc-gateway/docs/mapping/customizingyourgateway/#mutate-response-messages-or-set-response-headers.

If you are sure you want to return these headers from the gRPC server, you can use an OutgoingHeaderMatcher: https://grpc-ecosystem.github.io/grpc-gateway/docs/mapping/customizingyourgateway/#mapping-from-grpc-server-metadata-to-http-response-headers.

I hope that helps. If anything is unclear in the documentation, I would love to help you make a contribution to make this clearer to new users. I'm going to close this issue as I believe it has been answered.

[arturgaleno]

Yeah, thats helped a lot! Thank you for your support @johanbrandhorst !