Missing content-type header in grpc response

[Faithtosin (Faith Tosin Olapade)]

1. The problem I’m having:

I am getting missing content-type header in grpc response on the client side.

2. Error messages and/or full log output:

No error from caddy, only on the client

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

c. Service/unit/compose file:

Docker compose

version: "3.7"

services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - $PWD/Caddyfile:/etc/caddy/Caddyfile
      - $PWD/site:/srv
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
    external: true
  caddy_config:

d. My complete Caddy config:

Caddyfile

{
debug
servers {
                protocols h1 h2 h2c
        }
}
https://test.dev {
        #@grpc protocol grpc
        @grpc {
                header Content-Type application/grpc
        }
        handle @grpc {
                reverse_proxy https://testnet.com:9067 {
                        transport http {
                                versions h2c
                                tls
                                tls_insecure_skip_verify
                        }
                }
        }

        header {
          Access-Control-Allow-Headers *
          Access-Control-Allow-Methods *
          Access-Control-Allow-Origin *
        }
        @options {
          method OPTIONS
        }
        respond @options 204
}

[Mohammed90 (Mohammed Al Sahaf)]

Please fill out the full template. It’s necessary for any support.

[Faithtosin (Faith Tosin Olapade)]

Sure! I filled it out.

[Mohammed90 (Mohammed Al Sahaf)]

Still missing the logs

[Faithtosin (Faith Tosin Olapade)]

Debug logs looks normal. There are no errors on the server side. The missing content-type header in grpc response is on the client.

[Mohammed90 (Mohammed Al Sahaf)]

Without sharing logs, the best I can tell you is your upstream app is not behaving properly. The upstream IS responsible for setting the content-type. Other than that, you can intercept the response and inject the header.

reverse_proxy (Caddyfile directive) - Caddy Documentation

[francislavoie]

@Faithtosin

                reverse_proxy https://testnet.com:9067 {
                        transport http {
                                versions h2c

This is in conflict. If you’re using HTTPS, you’re not using H2C. H2C literally means “HTTP/2 Cleartext”, i.e. HTTP/2 without HTTPS. So it doesn’t make sense to set versions h2c if you’re proxying over HTTPS.

We need to see your reverse_proxy debug logs to see what’s actually going on.

@Faithtosin

        header {
          Access-Control-Allow-Headers *
          Access-Control-Allow-Methods *
          Access-Control-Allow-Origin *
        }

This doesn’t make sense, you’re literally setting those 3 response headers to the value *. That’s incorrect.