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

Setting Expires headers #308

Closed
maxrosecollins opened this issue Jun 11, 2015 · 15 comments
Closed

Setting Expires headers #308

maxrosecollins opened this issue Jun 11, 2015 · 15 comments

Comments

@maxrosecollins
Copy link

I noticed issue 39 fixed the issue for setting the expires HTTP header to the far-future. I don't know is amazon updated something but it doesnt work any more and none of my headers are being set.

@sbeam
Copy link

sbeam commented Jul 6, 2015

same issue here on S3/Cloudfront; I think it might have to do with sprockets not including the gzip files anymore, see #304. We are using the patch included there but the gzipped assets are not triggering the setting of the Expires header when uploaded. There is a patch in #223 that might address this.

$ curl -I http://xyz.cloudfront.net/assets/application-7f4d06566e2bcde97fecbbde60081bd6e2dcbe8f412a8105660c126a344e3bfb.css
HTTP/1.1 200 OK
Content-Type: text/css
Content-Length: 6772
Connection: keep-alive
Date: Mon, 06 Jul 2015 04:04:43 GMT
Content-Encoding: gzip
Last-Modified: Tue, 30 Jun 2015 14:50:49 GMT
ETag: "befa12908aa927161b6d9ac470d63054"
Accept-Ranges: bytes
Server: AmazonS3
Age: 45310
X-Cache: Hit from cloudfront
Via: 1.1 97425b66a3749ba768ba59108c1da79a.cloudfront.net (CloudFront)

@lime
Copy link
Collaborator

lime commented Jul 4, 2016

This seems to be caused by AssetSync assuming the hash to be 32 characters long, while the current hash used is 64.

Also, this has apparently already been fixed in #315, but not yet released.

@maxrosecollins
Copy link
Author

Okay, great news!

@PikachuEXE
Copy link
Member

I have no permission to release, so...
Lets wait?

@lime
Copy link
Collaborator

lime commented Jul 5, 2016

Yeah, I just read #316 and it sounds like @davidjrice would need to give out release rights for that to happen, right? I'll install from master until then.

@lime
Copy link
Collaborator

lime commented Jul 5, 2016

Okay, so the 64 char issue was solved in #315, but .gz assets are indeed not handled since #223 hasn't been merged. I could do a rebase of the fix on the current master.

@PikachuEXE
Copy link
Member

Please do so. Thanks!

@PikachuEXE
Copy link
Member

Please try master since #329 merged
And let us know if this issue is fixed

@davidjrice
Copy link
Contributor

@PikachuEXE good work. Would you like release rights?

@lime likewise!

@PikachuEXE
Copy link
Member

@davidjrice
Sure <3

I just realize the last release was made in 2014 (O.O)
Maybe you want to make a new one soon? (So I can follow the release style)

@lime
Copy link
Collaborator

lime commented Jul 5, 2016

@davidjrice I'm not that familiar with the codebase yet, so I wouldn't dare to make any big judgment calls. But I'm happy to help out as much as I can. :)

@johansmitsnl
Copy link

+1 for an release of the new features and cache control

@johan-smits
Copy link

@davidjrice Looking forward of a new release with this feature.
Is a release blocked for some reason?

@PikachuEXE
Copy link
Member

#329 should be released in 1.2.0 (a recent release)
See https://github.com/AssetSync/asset_sync/blob/master/CHANGELOG.md

@lime
Copy link
Collaborator

lime commented Aug 23, 2016

This should indeed be released now since 1.2.0.

I'll close the issue. If anyone notices problems with the cache headers after updating, please do comment or open an issue. :)

@lime lime closed this as completed Aug 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants