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 wonder if the current implementation of the HTTP Cache is really performant. To me, it looks like the cache middleware creates the whole response first and then compares the Last-Modified and ETag header of the response with the request to determine if a 304 status code should be returned. Therefore the complete response is created but will not be used, since Slim will not output the body if the status is 304.
In Slim 2 the abort method was used to immediately stop the execution as soon as the Last-Modified/ETag were set (assuming the client side cache was still valid). I think it would also be a good idea for Slim 3 to return the 304 response as soon as possible. This will make the usage a bit more verbose and not automagically, but will probably improve CPU/memory usage and response times.
For example, the current checks in the Cache middleware could be moved to a new method in the cache provider (e.g. isStillValid()):
$app->get('/foo', function ($req, $res, $args) {
$resWithEtag = $this['cache']->withEtag($res, 'abc');
if ($this['cache']->isStillValid($req, $res)) {
return$resWithEtag->withStatus(304); // or even another convenience method
}
// ... some intensive calls to create the response$resWithEtag->write($body);
return$resWithEtag;
});
The text was updated successfully, but these errors were encountered:
For anyone looking for a workable solution, middlewares/cache uses the right approach, but it -along with the underlying micheh/psr7-cache - hasn't been updated for a while either.
And yes, although it wasn't clear from the documentation or tests, this works fine with ETag as well as Last-Modified headers...
I added some ETag tests in mikespub-org/middlewares-cache@2040200
I wonder if the current implementation of the HTTP Cache is really performant. To me, it looks like the cache middleware creates the whole response first and then compares the
Last-Modified
andETag
header of the response with the request to determine if a304
status code should be returned. Therefore the complete response is created but will not be used, since Slim will not output the body if the status is304
.In Slim 2 the
abort
method was used to immediately stop the execution as soon as theLast-Modified
/ETag
were set (assuming the client side cache was still valid). I think it would also be a good idea for Slim 3 to return the304
response as soon as possible. This will make the usage a bit more verbose and not automagically, but will probably improve CPU/memory usage and response times.For example, the current checks in the Cache middleware could be moved to a new method in the cache provider (e.g.
isStillValid()
):The text was updated successfully, but these errors were encountered: