-
Notifications
You must be signed in to change notification settings - Fork 14
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
Nginx default etag and last-modified headers not working as expected #447
Comments
I tried |
This is not gonna happen in short term, as natalieparellano said:
As a workaround, we can implement finer cache control in another way:
A nginx.conf example:
Notes:
|
Thanks @uqix for commenting this issue. I suggest to not mix up things. This issue is about fixed timestamps for static files i.e. css, html and js. It's not about a read only root filesystem (see #463). Basically you turned cache control off, which is not what I would suggest on a general basis. As an intermediate solution we disabled
This way some basic caching should be working. |
Any update about this issue? The SOURCE_DATE_EPOCH env variable only manages the layers' creation time but doesn't change the zero epoch timestamp of application-related source/compiled files (but I think it should change the app-related files @natalieparellano |
@mecseid if we need layer timestamps to be configurable we could certainly add it, we would need an RFC similar to https://github.com/buildpacks/rfcs/blob/main/text/0103-source-date-epoch.md to describe how this would work in pack and the lifecycle. |
Describe the Enhancement
Currently a reproducible build is performed were my image contains my static files of a react front-end application.
Unfortunately, all files modified date at file system level is Jan 01 1980, because all image layers should be reproducible.
Nginx on the other hand uses last modified on file system level to notify clients about changed files. The HTTP headers used are etag and last-modified.
So if I deploy a new image with changed application layer, the client got the old headers and didn't invalidate it's cache.
Possible Solution
I recommend to introduce a flag which enable users of this buildpack to choose whether the original timestamp or 1980 is used for the web server root folder.
Motivation
A useful caching mechanism preserve users of a web application from manually invalidate their cache and therefore increase their experience.
The text was updated successfully, but these errors were encountered: