You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed a strange behavior while playing with HttpCache. Given I install a fresh standard edition, when I enable HttpCache with the following configuration :
Here's what I get on the first call (removed some headers for clarity). Everything looks fine :
HTTP/1.1 200 OK
Age: 0
Cache-Control: public, s-maxage=10
Date: Wed, 30 Apr 2014 07:30:04 GMT
X-Content-Digest: ena591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
X-Symfony-Cache: GET /demo/hello/World: miss, store
Hello World
During the time the cached response has not expired, it's fine too :
HTTP/1.1 200 OK
Age: 3
Cache-Control: public, s-maxage=10
Date: Wed, 30 Apr 2014 07:30:07 GMT
x-content-digest: ena591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
X-Symfony-Cache: GET /demo/hello/World: fresh
Hello World
However, when the cached response expires, we always go through the cache and hit the origin. Until the cache is cleared, you'll keep seeing :
HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Wed, 30 Apr 2014 07:30:37 GMT
X-Symfony-Cache: GET /demo/hello/World: stale, invalid
Hello World
I guess that what we would expect is that on the first call after expiration the new response sent by the origin gets stored. It would look like this :
HTTP/1.1 200 OK
Age: 0
Cache-Control: public, s-maxage=10
Date: Wed, 30 Apr 2014 07:34:04 GMT
X-Content-Digest: ena591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
X-Symfony-Cache: GET /demo/hello/World: stale, invalid, store
Hello World
Note : @alquerci already attempted to solve the problem here #8232 and here #9919. It would work but as Fabien stated, we cannot alter the role of the validate() method.
The text was updated successfully, but these errors were encountered:
… a default "global" TTL is defined (alquerci, fabpot)
This PR was merged into the 2.3 branch.
Discussion
----------
[HttpKernel] Fixed cache behavior when TTL has expired and a default "global" TTL is defined
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | #8232, #10822, #9919
| License | MIT
From #9919:
"When the cache is stale the `validate` method `forward` the request to the backend. A new response will be created with or without TTL configuration. If the TTL was not set then the default one should be set like in the `fetch` method."
This PR fixes this issue, the tests provided in #9919 pass, and I've tweaked them to avoid the costly sleep calls.
Commits
-------
e3983e8 [HttpKernel] fixed default TTL not applied under certain conditions
bc42dae Added test when TTL has expired
Hello,
I noticed a strange behavior while playing with HttpCache. Given I install a fresh standard edition, when I enable HttpCache with the following configuration :
Here's what I get on the first call (removed some headers for clarity). Everything looks fine :
During the time the cached response has not expired, it's fine too :
However, when the cached response expires, we always go through the cache and hit the origin. Until the cache is cleared, you'll keep seeing :
I guess that what we would expect is that on the first call after expiration the new response sent by the origin gets stored. It would look like this :
Note : @alquerci already attempted to solve the problem here #8232 and here #9919. It would work but as Fabien stated, we cannot alter the role of the
validate()
method.The text was updated successfully, but these errors were encountered: