Some assets don't get delivered anymore after update to 4.1.1 because of funky name conflict (dashes make them look like digest for the Regexp) #749
Comments
fwolfst
changed the title
|
|
Getting hurt by this now on development - when using importmaps, the |
fwolfst
changed the title
This is a fix for: rails#749 The bug is when you have two assets in the same path where one looks like the fingerprint-stripped version of the other, e.g. “landing.png” and “landing-splashimage.png”. In this case, if landing-splashimage.png is requested, a 404 is returned rather than the asset. The old behavior: The code had logic to first strip anything that looked like a fingerprint from the filename. Then, if the asset was not found with the stripped path, it would attempt to find it with the full_path. This “fallback” was to handle the case where the code mistakenly thought a filename with a dash actually had a fingerprint. But, if the stripped path had already matched a different asset, then a 404 would be returned since the matched asset’s etag wouldn’t match the fingerprint. The new behavior: This PR first looks up the asset using the original path. Only in the case where the asset is not found does the code strip what might be a fingerprint from the path and re-lookup. This new behavior fixes the bug and I think is more true to the spirit of what this code should be doing. Other changes / side effects: In the case where both the original asset and the fingerprinted asset exist, the new code returns the fingerprinted-asset while the old code returns the original asset. This should never result in any actual difference of bytes served. I think this is worth fixing because if the bug is encountered, it can be deeply confusing to the uninitiated and could waste hours of time.
|
This bit me too. And was pretty confusing to figure out what was going on. I created a PR (#793). Would love to see it merged. |
|
@flivni Awesome. If anyone needs a quick remedy, you can use this initializer |
|
I got bit by this, also. I think part of the issue might be very simple to resolve: the fingerprint detection regex could be tightened to only hexadecimal My hotfix initializer is very short: require "sprockets/server"
Sprockets::Server.prepend Module.new {
private def path_fingerprint(path)
path[/-([0-9a-f]{7,128})\.[^.]+\z/, 1]
end
}Will create a PR for this as well. |
Expected behavior
Our app flags 404s on SOME static assets. It should just serve out all assets are equal.
Actual behavior
404 for some static assets.
System configuration
We see this while migrating a Rails 6.1 Sprockets 4.0.3 Ruby 3.0.x to upstream versions (7.0, 4.1, 3.1).
Example App (Reproduction) - THIS IS IMPORTANT YOUR ISSUE LIKELY WILL NOT BE RESOLVED WITHOUT THIS
https://github.com/econya/sprockets_digest_muncher
The issue only happens if a pseudo "digest" is stripped from an existing asset file, e.g.
file-notadigestbutmatchesregexp.txtbecomesfile.txt(related commit: 53ce8d6).If now,
file.txtreally exists, this conflict will somehow grow into a RouteNotFound.See https://github.com/econya/sprockets_digest_muncher for easy reproducible instructions (its a vanilla rails 7.0.1 app without any modifications, see commits)
Btw, the code references
fingerprintanddigest- I assume its the same? Also, the regexp differ, not sure if they should and if it doesnt make sense to move it into a constant.It did not fail us earlier because our filenames contain letters outside of
[a-f]...The text was updated successfully, but these errors were encountered: