Access-Control-Expose-Headers

Help
1

Hello guys,
I’d like to return CORS with Access-Control-Expose-Headers header set to ‘grpc-message,grpc-status’.
As you can see, I’m using caddy for gRPC-web proxying… And I need these headers to be exposed…

My current Caddyfile’s domain’s cors config:
cors / {
origin http://<my_domain>.com
methods GET,POST,PUT,OPTIONS
allow_credentials false
max_age 3600
allowed_headers keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout
exposed_headers grpc-status,grpc-message
}
(Pretty much copy-paste from github getting-started section…)

But when I run caddy container… a try to use grpc client to send message to grpc server (to Caddy actually) I receive response in which the required header is set to something else… (probably Caddy just sets Access-Control-Expose-Headers to other visible headers…) but mine value is not listed there… and I also noticed different CORS responses between pre-flight requests and normal ones…

Thanks in advance…

2

Hi @TheMaikXX, welcome to the Caddy community!

Just to help me get a grasp of the issue, can you give a concrete example of a HTTP request that didn’t have the expected result, pointing out what it should have instead?

3

Hello @Whitestrake,

This is, for example (I used to use this proxy in the past), what Envoy proxy returns (which works):

image
image1920×1080 259 KB

For this configuration:

...

cors:
            allow_origin:
              - "*"
            allow_methods: GET, PUT, DELETE, POST, OPTIONS
            allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout
            max_age: "1728000"
            expose_headers: grpc-status,grpc-message
...

These values are required by grpc-web and I copied these values to Caddyfile config to specific section (I tried both of options specifying header and using http.cors plugin as well - not together of course):

 <my_api_domain> {
    header / {
            Access-Control-Allow-Origin http://chat.km-ubu-001.serv.keenmate.com
            Access-Control-Allow-Methods "GET, POST, OPTIONS"
            Access-Control-Allow-Headers "keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout"
            access-control-expose-headers "grpc-status,grpc-message"
    }
    # I tried one or another of these 2 possibilities..
    cors / {
            origin <my_domain>
            methods GET,POST,PUT,OPTIONS
            allow_credentials false
            max_age 3600
            allowed_headers keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout
            exposed_headers grpc-status,grpc-message
    }

    grpc vertx-web:9990 {
            backend_is_insecure
            backend_tls_noverify
    }

    log /var/log/requests.grpc.log {
            rotate_size 50
            rotate_age 90
            rotate_keep 20
            rotate_compress
    }

}

And the actual response from Caddy when grpc call initiated:

image
image1919×798 110 KB

As you can see the Access-Control-Expose-Headers header contains something that Caddy adds behind the scene atleast I guess…

The grpc-web also requires the Access-Control-Expose-Headers header to be set even for actual request (not just pre-flight handshake)

The problem pops up in the console, saying:
image

If you need any more info, tell me so…
Thanks

4

Can’t find anywhere that’s set hardcoded… If you remove the grpc directive entirely - maybe replace with status 200 / for a quick test - do you still get the wrong Access-Control-Expose-Headers?

5

Ok, commented grpc config and tested with cors plugin - no CORS headers at all…
and with header config it works now… the headers are there…

So it might be something with that grpc plugin… but after brief look at its repo I couldn’t find anything related to CORS headers…

6

Not hard-coded, no. I’m wondering if they’re coming down from vertx-web:9990, and overriding your other configuration because grpc executes well after header and cors do, so it gets the final word: https://github.com/mholt/caddy/blob/af8214180822b7ecfbc4a704848355a91b158039/caddyhttp/httpserver/plugin.go#L643-L686

7

Well I don’t do anything with cors in the API… but I will check Vertx server & gRPC plugin in API to be sure that these don’t override cors headers…

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.