-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Meta: HTTP Gateway cache control improvements #8717
Comments
Only thing I would add is a strategy of expiring at "top of the hour" or "end of the day" for the DirIndex pages makes dealing with when the etag does eventually change a bit nicer (you wont see different things on different servers for as long), which nudges me to prefer Expires to Cache-Control (but its not that much extra to calculate it anyway) |
An idea in addition to the ones proposed: |
@mathew-cf thats useful, but you'd have to rewrite to fetch |
By cacheable, I meant for a short TTL (~1 min). This resolution response can still be supplemented by DNS resolution for faster cache verification/invalidation. If you have the x-ipfs-roots header, you can check that the resolution and response match and choose whether to cache the response. I'm thinking in the context of using Cloudflare workers here if that helps clarify the context. |
@mathew-cf Thoughts on leveraging existing
|
@lidel That works for me! |
I tested something like your dir-index-html strategy with lua in nginx, but I used So configuring the name of the header might be useful is the concrete ask here, but someone else that uses another cache might be able to chime in |
If we fix https://github.com/ipfs/go-ipfs/issues/1818#issuecomment-1015849462 (set proper |
@lidel did fix/dir-index-html-max-age land somewhere? |
@thattommyhall kinda: #8758 fixed a bug and now adds Generated dir listings don't have |
I'd like to advocate for something like top of the hour Expires or something in the DirIndex case too. It's nice not to have to re-ask the backend at least for a short while |
@thattommyhall I am leaning towards setting Given how people deploy gateway infra, we would still want to revalidate on CDN/caching proxies, so how about:
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) My understanding is the caching proxy will always return a cached version of dir listing, but will try to revalidate if the cached copy is older than a week. Thoughts? |
This is a meta issue for HTTP cache improvements that we should prioritize in go-ipfs:
max-age
on/ipns/
based on TTL – https://github.com/ipfs/go-ipfs/issues/1818/ipfs/
should have some reasonablemax-age
(it won't change within releases)/ipns/
responses which contains resolved IPNS (root CID) for faster cache invalidation of entire website when IPNS pointer changesX-Ipfs-Roots
in feat: X-Ipfs-Roots for smarter HTTP caches #8720 a way to indicate all CIDs required for resolving path segments fromx-ipfs-path
cc @thattommyhall & @mathew-cf) if there are more asks/ideas here
The text was updated successfully, but these errors were encountered: