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

Need to introduce HTTP Cache control #1121

Open
baudoliver7 opened this issue Apr 20, 2022 · 9 comments
Open

Need to introduce HTTP Cache control #1121

baudoliver7 opened this issue Apr 20, 2022 · 9 comments

Comments

@baudoliver7
Copy link
Contributor

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:

@baudoliver7
Copy link
Contributor Author

@yegor256 WDYT about this issue ?

@yegor256
Copy link
Owner

@baudoliver7 I'm not against it, but how will it work? Can you give a usage example?

@baudoliver7
Copy link
Contributor Author

baudoliver7 commented Apr 20, 2022

@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 ! :-)

@yegor256
Copy link
Owner

@baudoliver7 it seems we already have something with a similar functionality, don't we?

@baudoliver7
Copy link
Contributor Author

@yegor256 I could be wrong but after checking, I haven't seen a take that works like this.

@baudoliver7
Copy link
Contributor Author

baudoliver7 commented Apr 21, 2022

@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
Copy link
Owner

@baudoliver7 let's do it then

@baudoliver7
Copy link
Contributor Author

baudoliver7 commented Apr 22, 2022

@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.

@yegor256
Copy link
Owner

@baudoliver7 yes, TkCachedFiles sounds like a good name

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

No branches or pull requests

3 participants