takes
takes copied to clipboard
yegor256
Need to introduce HTTP Cache control
To optimize bandwidth usage, we need sometimes to put in cache some static files.
HTTP Cache control obeys to the norm RFC 7234.
There are some useful links:
- https://developer.mozilla.org/en/docs/Web/HTTP/Headers/Cache-Control
- https://www.imperva.com/learn/performance/cache-control/
@baudoliver7 I'm not against it, but how will it work? Can you give a usage example?
@yegor256 We could introduce a new decorator of Take named for example TkCachedFiles that we can call like this:
new TkCachedFiles (
origin, // take to decorate
maxage, // Max age in second
"css", "js", "png" // list of extensions of files to cache
)
When we try to request for example a css file for the first time, TkCachedFiles will add in response headers two headers:
Cache-Control: public, max-age=<max age>
ETag: <md5 file>
By these headers, the browser will cache the file for the max age under the ETag. Cache of the file is removed by the browser as soon as max age is reached.
During the second request, TkCachedFiles will check that the header If-None-Match is present (it is managed by the browser) and contains the ETag value. In this case, TkCachedFiles will return 304 status code without a body. By this, the browser will understand (according to the norm) that it must use the file already put in cache.
Long life to decorator pattern ! :-)
@baudoliver7 it seems we already have something with a similar functionality, don't we?
@yegor256 I could be wrong but after checking, I haven't seen a take that works like this.
@yegor256 I just found someone else that has explained the same idea in this open issue (#933) but there is no PR that resolves the problem.
@yegor256 TkCachedFiles is a good name ?
Besides, I think it will be good if we leave to the developer the choice of how to produce a unique identifier for ETag.