use shorthash for data url image to prevent ENAMETOOLONG #12108
Conversation
🦋 Changeset detectedLatest commit: 55f48bb The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
github-actions
bot
added
the
pkg: astro
There was a problem hiding this comment.
The code looks good to me, but I let @Princesseuh double check
| <Image src={data} alt="transparent" width="128" height="72" /> | ||
| </div> | ||
| <div id="data-url-no-size"> | ||
| <Image src={data} inferSize={true} alt="transparent" /> |
There was a problem hiding this comment.
I honestly had no idea inferSize worked with data urls, pretty neat, though since we have all the data, we could make it so it's not required, ha.
There was a problem hiding this comment.
Works with me, thank you!
This highlights a few flaws with the handling of data URIs, notably that they're considered remote images and so you need to add a remote pattern. Ideally, they'd be treated like some sort of in-between remote and local images and you wouldn't need any config, something for another PR, though.
Changes
currently data: urls are treated like normal urls and
basenameis used to get the filename to generate the cache and output files. however this can result in a very long filename depending on where the slashes (which are part of the base64 data) are, possibly resulting in errors.to prevent this, can instead use a shorthash of the data url as the filename for data url images processed. so the final output image filename will be
[hash of data url]_[hash].[ext]instead of[arbitrary basename of data url]_[hash].[ext]Testing
added text fixture which processes data url images which would cause ENAMETOOLONG
Docs
should have no effect on user behaviour