Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not always define Vary header #287

Closed
2 tasks done
saschanaz opened this issue Dec 26, 2023 · 1 comment · Fixed by #288
Closed
2 tasks done

Do not always define Vary header #287

saschanaz opened this issue Dec 26, 2023 · 1 comment · Fixed by #288

Comments

@saschanaz
Copy link
Contributor

saschanaz commented Dec 26, 2023

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.24.3

Plugin version

8.5.0

Node.js version

20.10.0

Operating system

Windows

Operating system version (i.e. 20.04, 11.3, 10)

11

Description

The Fetch standard says:

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]

In particular, consider what happens if Vary is not used and a server is configured to send Access-Control-Allow-Origin for a certain resource only in response to a CORS request. When a user agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lack Access-Control-Allow-Origin and the user agent will cache that response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, without Access-Control-Allow-Origin.

But if Vary: Origin is used in the same scenario described above, it will cause the user agent to fetch a response that includes Access-Control-Allow-Origin, rather than using the cached response from the previous non-CORS request that lacks Access-Control-Allow-Origin.

However, if Access-Control-Allow-Origin is set to * or a static origin for a particular resource, then configure the server to always send Access-Control-Allow-Origin in responses for the resource — for non-CORS requests as well as CORS requests — and do not use Vary.

fastify/cors seems to always define the Access-Control-Allow-Origin if origin is * or a string, and in that case setting Vary sounds like a bug.

Seems the regressor is #45.

Steps to Reproduce

  1. Copypaste the example usage to fastify-cors.js
import Fastify from 'fastify'
import cors from '@fastify/cors'

const fastify = Fastify()
await fastify.register(cors, {
  // put your options here
})

fastify.get('/', (req, reply) => {
  reply.send({ hello: 'world' })
})

await fastify.listen({ port: 3000 })
  1. Run node fastify-cors.js
  2. See the Vary header is set as Origin even for the simple browser navigation.

Expected Behavior

Vary should not be set for simple cases.

@mcollina
Copy link
Member

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants