Traefik is removing Access-Control-Allow-Origin headers from the service response about traefik HOT 6 OPEN

Hi @GiamBoscaro

Thanks for your issue.

Could you please provide us a simple reproductible use case without usage of the corporate proxy?

from traefik.

Hi @GiamBoscaro

Thanks for your issue.

Could you please provide us a simple reproductible use case without usage of the corporate proxy?

I will try to setup a working example without the proxy when I have time. Do you think it is something related to the corporate proxy? It is strange because any other service or website doesn't have this problem.
Would be really great to know how Traefik is supposed to work also, clearly understanding this would be already a big help for me: if I do not configure any cors middleware in Traefik, should Traefik just forward the response headers coming from the backend service to the client, including cors headers (in particular allow origin) ?

from traefik.

Hi @GiamBoscaro

Thanks for your issue.

Could you please provide us a simple reproductible use case without usage of the corporate proxy?

Good morning, an update on the situation. I have have done some testings with the corporate proxy, and I have figured out that my requests are NOT passing through the corporate proxy, since the domains that I am using in the internal network. This means two things:

1. It is Traefik that it is rewriting the headers lower case
2. It must be Traefik that is somehow not forwarding the allow origins header in the response.

This is the response when CORS middleware is NOT set:

access-control-allow-credentials: true
access-control-allow-headers: Content-Type,Authorization,Accepts,Set-Cookie,Cookie,Range
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-expose-headers: Accept-Ranges, Content-Encoding, Content-Length, Content-Range
alt-svc: h3=":443"; ma=2592000
date: Mon, 19 Feb 2024 09:21:00 GMT
vary: Origin
x-powered-by: Express

This is the response when CORS middleware is set:

access-control-allow-credentials: true
access-control-allow-headers: Content-Type,Authorization,Accepts,Set-Cookie,Cookie,Range
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-origin: https://my-domain.com
access-control-max-age: 600
alt-svc: h3=":443"; ma=2592000
content-length: 0
date: Mon, 19 Feb 2024 09:24:35 GMT

from traefik.

Hello @GiamBoscaro,

I tried to reproduce the issue with a Go backend and an Express one but without any success. The Access-Control-Allow-Origin header is not removed by Traefik and is forwarded as is to the Client (without using the CORS middleware in Traefik).

Could you please provide a reproducible use case to help us diagnose the issue?

from traefik.

I had the same issue (docker image traefik:2.11).

It manifested for me when sending an OPTIONS request with access-control-request-method: OPTIONS and origin: https://ANYTHING headers.

traefik would always respond with the following without ever forwarding the request to the application:

HTTP/1.1 200 OK
Access-Control-Max-Age: 0
Date: Thu, 18 Apr 2024 21:51:56 GMT
Content-Length: 0
Connection: close

When I removed the addVaryHeader: true option, requests were forwarded normally and I got the headers that my app generated.

Example with addVaryHeader: true enabled:

$ curl -sv https://my-domain.example.org \
  -X OPTIONS \
  --header 'access-control-request-method: OPTIONS' \
  --header 'origin: https://example.org'
...
> OPTIONS / HTTP/2
> Host: my-domain.example.org
> User-Agent: curl/8.7.1
> Accept: */*
> access-control-request-method: OPTIONS
> origin: https://example.org
>
* Request completely sent off
< HTTP/2 200
< access-control-max-age: 0
< content-length: 0
< date: Thu, 18 Apr 2024 21:56:38 GMT
<
* Connection #0 to host my-domain.example.org left intact

Example response from my app with the addVaryHeader removed from the configuration:

$ curl -sv https://my-domain.example.org \
  -X OPTIONS \
  --header 'access-control-request-method: OPTIONS' \
  --header 'origin: https://example.org'
...
> OPTIONS / HTTP/2
> Host: my-domain.example.org
> User-Agent: curl/8.7.1
> Accept: */*
> access-control-request-method: OPTIONS
> origin: https://example.org
>
* Request completely sent off
< HTTP/2 204
< access-control-allow-credentials: true
< access-control-allow-headers: *
< access-control-allow-methods: OPTIONS
< access-control-allow-origin: https://example.org
< date: Thu, 18 Apr 2024 22:01:53 GMT
< permissions-policy: interest-cohort=()
< referrer-policy: no-referrer-when-downgrade
< vary: Origin, Access-Control-Request-Method
...

I don't know whether this is the only situation, but replacing OPTIONS with GET (both method and header) works like it should.

from traefik.

Bump!

Setting the ORIGIN in my Dockerfile, re-establishes this missing header, which patches my issue for now.

I'd love to see more attention on this issue.

from traefik.