-
Notifications
You must be signed in to change notification settings - Fork 248
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
Stop serving non-digested images in development? #117
Comments
That makes sense. Been bit by this recently and shortening the feedback loop so that we know it won't work while still in development would save us devs a lot of time. Still even having trouble now with my code where I dynamically generate the url to my images in a coffee.erb file. Have code that looks like: It works fine in development but haven't yet figured out why it isn't working production(Heroku). Just saying, would be great if anyone could give insights too. |
If config.assets.digest = true and app.config.assets.raise_runtime_errors = true, we don't serve up assets without digests. Here are the different cases: - If the asset request has a digest and it matches the asset's digest, we serve the asset. - If the asset request has a digest and it does not match the asset's digest, we redirect to the asset. - If the asset request does not have a digest, we raise a NoDigestError. Fixes rails#117
If config.assets.digest = true and config.assets.raise_runtime_errors = true, only serve an asset if the request has a digest. Here are the different cases: - If the asset request has a digest and it matches the asset's digest, we serve the asset. - If the asset request has a digest and it does not match the asset's digest, we redirect to the asset. - If the asset request does not have a digest, we raise a NoDigestError. Fixes rails#117
If config.assets.digest = true and config.assets.raise_runtime_errors = true, only serve an asset if the request has a digest. Here are the different cases: - If the asset request has a digest and it matches the asset's digest, we serve the asset. - If the asset request has a digest and it does not match the asset's digest, we redirect to the asset. - If the asset request does not have a digest, we raise a NoDigestError. Fixes rails#117
If config.assets.digest = true and config.assets.raise_runtime_errors = true, only serve an asset if the request has a digest. Here are the different cases: - If the asset request has a digest and it matches the asset's digest, we serve the asset. - If the asset request has a digest and it does not match the asset's digest, we redirect to the asset. - If the asset request does not have a digest, we raise a NoDigestError. Fixes rails#117
If config.assets.digest = true and config.assets.raise_runtime_errors = true, only serve an asset if the request has a digest. Here are the different cases: - If the asset request has a digest and it matches the asset's digest, we serve the asset. - If the asset request has a digest and it does not match the asset's digest, we redirect to the asset. - If the asset request does not have a digest, we raise a NoDigestError. Fixes rails#117
This is a follow up from some of the issues resolved in #84: "Match Dev Asset Experience to Production". This pull request solved issues where assets not flagged to be precompiled would work in development, but then break in production.
I've been having another issue related to development/production parity, where sprockets-rails will happily serve up non-digested images in development if they are statically linked to. This will of course not work in production, as all images are digested.
For example, a JS file might (erroneously) do something like:
I'm proposing that we make development behave the same as production, and refuse to serve non-digested images. This could raise an exception or just 404, and could perhaps use the same config flag as #84 does.
I haven't dug into the code yet, but does this sound like something worth putting together a pull request for?
The text was updated successfully, but these errors were encountered: