Abort execution early if client side cache is still valid

[micheh]

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]

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

[Maks3w]

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

Delegates to Slim\App::isEmptyResponse