Body is still sent on 304

[JimTools]

There is odd behaviour around cache hits, the whole idea of the 304 status is to reduce data transmission if the browser/client has data which is still accurate.

I've noticed that the response body isn't truncated defeating the purpose, technically this isn't a bug nor an implementation issue I still think it's incorrect behaviour.

While the developers can work around this by handling it in their projects, I feel like this package should handle this.

RFC-9110 MDN 304

[odan]

I think this could be handled very easy with a custom middleware. Check for the response status code == 304 and return a response with an empty response body.

[akrabat]

This is a little weird as the checks where a 304 is returned are after all the work has been done.

i.e. I'm unclear why the etag and last modified checks aren't done by the handler before doing the work? I suppose that there's some benefit to the client in knowing that nothing's changed, but on this server-side, it seems suboptimal.

[mikespub]

This is a little weird as the checks where a 304 is returned are after all the work has been done.

i.e. I'm unclear why the etag and last modified checks aren't done by the handler before doing the work? I suppose that there's some benefit to the client in knowing that nothing's changed, but on this server-side, it seems suboptimal.

Hi @akrabat the approach in slim/http-cache 1.3.0 is still flawed that way I'm afraid - see issue #10 from 2015 by micheh, who provides a better approach for GET/HEAD requests with middlewares/cache. That will basically cache HTTP response headers based on URI, and only handle the full request if headers don't match (on ETag, Last-Modified etc.)

But to be fair, if there's an intermediate cache device between the browser and the server, then this should make it work...