8000 Cache cannot distinguish between OPTIONS and GET · Issue #20202 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content
Cache cannot distinguish between OPTIONS and GET #20202
Closed
@nico-incubiq

Description

@nico-incubiq

Hello,

I just ran into an issue with Symfony 3.1.5 concerning the HttpCache mechanism, which sends back the content of a GET method while executing an OPTIONS call.
I have a JS application which calls an API. This app uses CORS preflight OPTIONS calls to determine if he can call the API. Cache is configured on some public APIs.

On a basic example here is what happens:

  • OPTIONS call from the JS app returns the right Response with headers such as "access-control-allow-methods: GET" and "cache-control: no-cache" (if I do it multiple times using Postman it always generates a new Response with the expected content, so that I am sure it is not cached)
  • GET call issued just after returns a Response with headers such as "cache-control: max-age=86400, public, s-maxage=86400" (this one is being cached by HttpCache, which stores it in a file on the server)
  • But when another computer accesses the page, the OPTIONS call returns a cached Response, with "cache-control: max-age=86400, public, s-maxage=86400"

I found that because the Store::generateCacheKey() method only uses the Uri to compute the cache the key, then HttpCache thinks it has found a cached version of the OPTIONS call and sends back the headers and body of the GET call instead.

I think the generateCacheKey should at least use the method when computing the key, and maybe headers like Accept-*.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0