{"action":"opened","issue":{"url":"https://api.github.com/repos/slimphp/Slim-HttpCache/issues/10","labels_url":"https://api.github.com/repos/slimphp/Slim-HttpCache/issues/10/labels{/name}","comments_url":"https://api.github.com/repos/slimphp/Slim-HttpCache/issues/10/comments","events_url":"https://api.github.com/repos/slimphp/Slim-HttpCache/issues/10/events","html_url":"https://github.com/slimphp/Slim-HttpCache/issues/10","id":95125992,"number":10,"title":"Abort execution early if client side cache is still valid","user":{"login":"micheh","id":1307920,"avatar_url":"https://avatars.githubusercontent.com/u/1307920?v=3","gravatar_id":"","url":"https://api.github.com/users/micheh","html_url":"https://github.com/micheh","followers_url":"https://api.github.com/users/micheh/followers","following_url":"https://api.github.com/users/micheh/following{/other_user}","gists_url":"https://api.github.com/users/micheh/gists{/gist_id}","starred_url":"https://api.github.com/users/micheh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/micheh/subscriptions","organizations_url":"https://api.github.com/users/micheh/orgs","repos_url":"https://api.github.com/users/micheh/repos","events_url":"https://api.github.com/users/micheh/events{/privacy}","received_events_url":"https://api.github.com/users/micheh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-07-15T07:34:25Z","updated_at":"2015-07-15T07:34:25Z","closed_at":null,"body":"I wonder if the current implementation of the HTTP Cache is really performant. To me, it looks like the cache middlewear 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`.\r\n\r\nIn 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.\r\n\r\nFor example, the current checks in the Cache middlewear could be moved to a new method in the cache provider (e.g. `isStillValid()`):\r\n```php\r\n$app->get('/foo', function ($req, $res, $args) {\r\n    $resWithEtag = $this['cache']->withEtag($res, 'abc');\r\n\r\n    if ($this['cache']->isStillValid($req, $res)) {\r\n        return $resWithEtag->withStatus(304); // or even another convenience method\r\n    }\r\n\r\n    //  ... some intensive calls to create the response\r\n    $resWithEtag->write($body);\r\n\r\n    return $resWithEtag;\r\n});\r\n```"}}