Added support for Last-Modified and ETag#8
Conversation
| $cacheItem->set($data)->expiresAfter($this->config['cache_lifetime'] + $data['expiresAt']); | ||
| $this->pool->save($cacheItem); | ||
|
|
||
| return $this->createResponseFromCacheItem($cacheItem); |
There was a problem hiding this comment.
What if the server responds with 304 but there is no cache?
There was a problem hiding this comment.
We do now that it is a cache. Or else the If-Modified-Since and If-None-Match would not have been added. And correct me if I'm wrong but I don't think the server will answer 304 without those headers in the request.
There was a problem hiding this comment.
Yes, those headers may have been added before. I'll just make sure to pass the response then.
|
Why do we need cache lifetime? Normally the server tells us how long it should be cached, doesn't it? |
|
Yes, but we would like to have the possibility to serve an expired response if the server answers 304. |
|
T0: We make a request. Server responds saying the response is valid until T10. Return response form server |
| $item->isHit()->willReturn(false); | ||
| $item->set(['response' => $response, 'body' => $httpBody])->willReturn($item)->shouldBeCalled(); | ||
| $item->expiresAfter(60)->willReturn($item)->shouldBeCalled(); | ||
| $item->set()->willReturn($item)->shouldBeCalled(); |
There was a problem hiding this comment.
I can't figure out a good way to write this line. I cant specify the exact data since it is dependent on time().
Can I say $item->set(<any argument>)->willRetu....?
|
I've figured out the tests and I found some bugs. Im done with the code changes and this PR is ready for review. |
| private function configureOptions(OptionsResolver $resolver) | ||
| { | ||
| $resolver->setDefaults([ | ||
| 'cache_lifetime' => 2592000, // 30 days |
There was a problem hiding this comment.
might be clearer to actually have an arithmetic expression here since it's only executed once
|
Thank you @GrahamCampbell. I've update the PR according to your suggestions. |
[ci skip] [skip ci]
| function let(CacheItemPoolInterface $pool, StreamFactory $streamFactory) | ||
| { | ||
| $this->beConstructedWith($pool, $streamFactory, ['default_ttl'=>60]); | ||
| $this->beConstructedWith($pool, $streamFactory, ['default_ttl'=>60, 'cache_lifetime'=>1000]); |
| $this->beConstructedWith($pool, $streamFactory, ['default_ttl'=>60, 'cache_lifetime'=>1000]); | ||
| $this->beConstructedWith($pool, $streamFactory, [ | ||
| 'default_ttl' => 60, | ||
| 'cache_lifetime'=>1000 |
| } | ||
| } | ||
|
|
||
| return; |
There was a problem hiding this comment.
don't need this statement?
There was a problem hiding this comment.
yeh, i replied there
| $cacheItem | ||
| ->expiresAfter($this->config['cache_lifetime'] + $maxAge) | ||
| ->set([ | ||
| 'response' => $response, |
There was a problem hiding this comment.
is this one level not enough indented?
There was a problem hiding this comment.
Thank you. But shouldn't StyleCi pick this up?
There was a problem hiding this comment.
Symfony has no rules about indentation like this I think?
|
Looks good. I've not physically tested this in the real world yet though. |
| $maxAge = $this->getMaxAge($response); | ||
| $currentTime = time(); | ||
| $cacheItem | ||
| ->expiresAfter($this->config['cache_lifetime'] + $maxAge) |
There was a problem hiding this comment.
Why are we doing this please?
There was a problem hiding this comment.
We would like to serve Responses that the server once said should expire.
See #8 (comment)
There was a problem hiding this comment.
when doing cache validation, we keep outdated caches and send If-Modified-Since / If-None-Match requests to the server to check if the cache is ok to be used. we might add some comment in the code though, to make it clear.
|
went over the code, looks good to me. for a moment i was wondering about stale-while-validate but this is just content validation and not advanced proxy operations. in async mode we theoretically could use stale-while-validate to return the expired response and re-fetch to our local cache. but this has nothing to do with this PR and anyways seems like a bad use case - one should use a dedicated caching proxy for such things, not implement this on client side. |
|
TODO:
|
|
We use issets. This PR is ready to be merged |
|
Thanks, will tag a release soon. |
|
Awesome. Thank you for all the reviews and feedback. |
What's in this PR?
We should allow the server to answer 304 which allows us to use a response in the cache.
The BC break here is that all existing items in the cache will be invalid. Is that an issue? It is a cache and not a storage.
I introduced a new config parameter
cache_lifetimethat says how long the item should be in cache without it being used.I did also add a few parameters to the array we store in the cache such as
expiresAt,createdAt,etag.To Do