fix: Responses vary with the origin if it is CORS #24

[yinheli]

No description provided.

[barryvdh]

Can you explain your problem? I don't this is correct, the Vary is added either way, unless it allows a single origin, or all origins.

[yinheli]

After integrating the CORS middleware, I found that for normal requests, there was an additional response header of "Vary: Origin". I think this is not necessary. If the request itself is not a cross-origin request, this should not disrupt the original logic.

I'll update a unit test to illustrate this.

[barryvdh]

But if CORS is enabled for the route, the response will vary depending on the Origin header, so you cannot cache it.

[yinheli]

Even if we have our own cache design, is it still not okay? Because I want to simplify the settings and make all routes support cross-domain.

If it always returns 'Vary Origin', in fact, ordinary requests do not have this 'Origin' request header.

Fetch Standard It seems that there was no clear statement of this requirement.

Or consider taking this as a configuration option? If the configuration doesn't always return "Vary Origin", it might cause caching issues? But users can still choose to disable the always return option.

[barryvdh]

What do you mean? That links states that it is required, right?

If CORS protocol requirements are more complicated than setting Access-Control-Allow-Origin to * or a static origin, Vary is to be used. [HTML] [HTTP] [HTTP-CACHING]

[yinheli]

I have revisited the CORS-preflight fetch process and the Vary: Origin example.

I think the current implementation makes sense. By always responding with Vary: Origin for routes that enable cross-origin requests, we can avoid issues with CDN caching.

Assuming our service did not previously support CORS and now integrates this lib to support CORS, the response will include Vary: Origin.

However, if I choose not to always respond with Vary: Origin:

A regular request, without the Origin header:

GET /api/resource HTTP/1.1
Host: example.com

A cross-origin request, with the Origin header:

GET /api/resource HTTP/1.1
Host: example.com
Access-Control-Request-Method: GET
Origin: http://example.org
Host: example.com

If the CDN caches the first request, it will return the cached response for the second request, leading to a failure of the cross-origin request.

I apologize for raising an issue that wasn't well thought out. I appreciate the opportunity to learn more about the subject.

Reference:

• https://httpwg.org/specs/rfc9111.html#constructing.responses.from.caches