-
Notifications
You must be signed in to change notification settings - Fork 110
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
Caching issues with --prefix-paths #215
Comments
Hi, thanks for reaching out. Please note that prefixes are something that we're still working on. They are a pain point for a lot of our users. (See gatsbyjs/gatsby#27988, #208, and #24). Based on your description, I think you want to upload objects to S3 with the _gatsby prefix, but viewers of your website would still navigate to the root of the domain, (_gatsby should not appear in the address bar), is that correct? If so, instead of using Gatsby's If I misunderstood and you want the |
No, we are incrementally migrating our site to gatsby. So the bucket has the same structure as of being served from the root. So for example if someone requests Since we can't add such rederiction rules for each file that gatsby generates, we used the |
Ah, so you're using We don't current have native support for this. But we do provide the ability for you to define your own rules for parameters applied to objects, see here. You should be able to use this to ensure the correct caching rule is applied. {
"_gatsby/page-data/**/**.json": {
"CacheControl": "public, max-age=0, must-revalidate",
}
} Keep in mind that metadata-only changes are not published for existing objects, this is a known limitation. You will need to delete any existing objects from the bucket prior to deployment in order for the new metadata to be applied. |
Ah cool! Didn't know about Thanks, that looks promising will test that out. I guess this kind of ends with a feature request then, which is that it should be super cool to support a local |
Maybe an option would be to allow configuring the upload of pages and assets seperately. You could choose to use this plugin to deploy assets, pages, or both. If both, you could upload them to the same bucket, or to two different buckets. Anyway, I think it's pretty niche so I don't think we'll prioritise it, but if you want to submit a PR for this functionality I'd be happy to review it. |
Cool! Totally agree with you, haven't seen that the gatsby docs suggesting to use the |
Hello,
In our current setup, some of our pages are built with gatsby and hosted on s3. For these pages we have added redirects for some specific urls in our web proxy. Since we are doing that we can't put the assets at root (as example
/styles.785b0331f15c65aecdef.css
needs to be/_gatsby/styles.785b0331f15c65aecdef.css
), which is why we are using the--path-prefix
with_gatsby
, which we have added a rule for in our external proxy.However, we still want to publish/host our assets in the same bucket as we use for the
html
-pages. I noticed that you ignore all assets files if the--prefix-paths
is set. We kind of found a hack to get around this, which is to take all the asset files and put them in a directory inside the build directory (named_gatsby
) and your plugin will manage the upload beautifully.However, it seems as we have some cache problems with the
page-data.json
-files. It seems as the metadata for the cache control is not correctly set. I guess it's because of this rule, which won't match since thepage-data
is prefixed with/_gatsby/page-data/**/**.json
Do you have any brilliant ideas on how we can solve the issue?
The text was updated successfully, but these errors were encountered: