-
Notifications
You must be signed in to change notification settings - Fork 11
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
add ETag to header output #52
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If using ETag, the hard-coded Cache-Control value might be confusing.
@kbrandwijk what do you suggest? I think because the images basically will never change - because if you change the image on graphcool it will be a new file anyways - the hardcoded cache value basically let the file stay in cache more-less forever? I think thats alright in this context. |
You are actually right! But if resources never change, what's the use for using ETag? Also, when using ETag, if you would query the server with |
@kbrandwijk I want to get rid of downgrade in PageSpeed and YSlow due to missing Expired or ETag in the imageproxy. So what do you think is the right approach? Only show I was reading through several posts and it seems that As far as I understand if 304 is the response and the ETag hasnt changed the browser will fetch the correct image and extends the lifetime of the cached image based on the max-age.
For me this is all new topic so I was reading through many blog posts to make sure doing the right thing. https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching |
@dohomi You are mostly right. I'm just saying that in order to provide a meaningful implementation of the ETag header, the part that says: 'return a 304' should also be implemented, which isn't part of the implementation right now. Also, returning the ETag from S3 might not be sufficient, because all the processing (cropping, resizing etc.) happens after the image is retrieved from S3. This would mean that different representations (based on the cropping/resizing arguments) would return the same ETag, which is also not right. I like the idea of supporting ETag, but I think it should be supported properly, instead of just passing along a header from S3. In my opinion, these things are missing right now:
|
@kbrandwijk you are right, I added the npm To return a proper 304 we would need to extract the right header from the |
I think I found a way. Could you have a look if that looks alright to you? |
@kbrandwijk @schickling I cloned this project and tested the behaviour on my aws account and it worked as expected. Anything I can do to get this merged? |
Add ETag to header output based on s3 ETag
Attempt to close #13
@schickling can you have a look? Thanks!