Define a custom max age on a request is not respected.
It s usually not a big deal except when it comes to custom access routes.
When i have a endpoint with GET and custom access (in my case it s a JWT Bearer Token), if the JWT is not valid, the endpoint is stuck in 403 cache.
I discovered that the method setResponseHeaders of RequestHandler class is responsible.
The X-TTL header is defined to a specific TTL no matter what is configured for the endpoint.
We should be able to respect the max-age defined.
However, it seems easier to say that done.
I have an idea for how to fix this but i am bit afraid of the side effects.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3561176-3.patch | 776 bytes | arnaud-brugnon |
| #2 | 3561176.patch | 1.06 KB | shumer |
Issue fork adv_varnish-3561176
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
shumer commentedHello,
if you can try to apply this patch and give a feedback would be nice.
What Changed:
The setResponseHeaders() method now respects the Cache-Control max-age directive if it's already set in the response before applying the configured TTL.
How it works now:
1. The code extracts the TTL from the configured cache settings as before
2. It checks if the response already has a Cache-Control header with a max-age directive
3. If found, it extracts the max-age value and uses it for the X-TTL header instead
Comment #3
arnaud-brugnon commentedI have to admit it s a bit ugly.
I thought about something easier
Comment #4
shumer commentedComment #5
shumer commentedAfter computing TTL from config, check the response's Cache-Control header for two explicit directives:
We deliberately check s-maxage (shared cache directive) rather than max-age, because Drupal core sets max-age=0 on all dynamic cacheable responses by default - if we respected it, nothing would ever be cached by Varnish. The s-maxage directive, on the other hand, is explicitly set by application code specifically for shared caches like Varnish.
How to use: If your endpoint needs to prevent Varnish caching (e.g. error responses, JWT failures), set Cache-Control: no-store on the response. If you need a custom TTL shorter than the module default, use s-maxage:
Comment #8
shumer commented