Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abort execution early if client side cache is still valid #10

Open
micheh opened this issue Jul 15, 2015 · 3 comments
Open

Abort execution early if client side cache is still valid #10

micheh opened this issue Jul 15, 2015 · 3 comments

Comments

@micheh
Copy link

micheh commented Jul 15, 2015

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;
});
@campersau
Copy link

+1 for a method to check if the cache from the client is still valid.

@Maks3w
Copy link

Maks3w commented Feb 7, 2016

Additionally it only change the HTTP status code but not remove the body.

Delegates to Slim\App::isEmptyResponse

@mikespub
Copy link

Still not fixed in 2023 with Slim 4

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.

You'll find updated packages at mikespub/middlewares-cache and mikespub/micheh-psr7-cache

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants