Querying SVGs has suddenly broken. All my images that are SVGs are coming up blank.
I looks like the format of the query params at the end of asset URLs has changed and no longer starts with a ?, so when I add my params starting with & as per the docs, e.g. ${img.url}&dpr=2, the result is a broken link e.g. ... logo.svg&dpr=2
This was all working as normal a few hours ago.
Hey @Pau do you know what’s going on here?
Hey Sean, could you share with me the query and the file that is causing you problems so I can test it on my end?
This is one image: https://prismic-io.s3.amazonaws.com/commercial-helios/ac82880a-40b6-43b9-975f-2f5d44310463_capterralogo.svg&h=60&dpr=2
The query for that looks like this: ${item.icon.url}&h=60&dpr=2
I cannot access the URL because your repository is private. Could you send the file in a zip file?
I removed the params at the end (which are what’s causing the problem)
I also get AccessDenied when trying to view WITH the params
Ok so only one thing was missing, you need to add ? instead of & at the end of the URL and it’ll work: https://prismic-io.s3.amazonaws.com/commercial-helios/ac82880a-40b6-43b9-975f-2f5d44310463_capterralogo.svg?h=60&dpr=2
Hi Sean,
I saw something like this last week and it is indeed the query params at the end of the URL causing the issue.
What’s strange is that you say all svg images were working with these params a few hours before because I would have thought it wouldn’t work at all, maybe I’m wrong.
I’ve done up an example site to show the issue here: https://zen-borg-41e93b.netlify.app/gb
and you can find the code here: https://github.com/mrseanbaines/prismic-previews-multi-locale/blob/svg-bug/src/templates/index.js#L13-L25
Here I’ve rendered two images, one SVG and one PNG. They are both rendered in the same way:
<img src={`${data.image.url}&w=100&dpr=2`} />
I’m using image processing query params to crop/resize etc., as per the documentation here: https://prismic.io/docs/gatsby/misc-topics/image-imgix-optimization#1_4-image-transformations
The image URL I get back from Prismic returns this for the PNG image: https://images.prismic.io/previews/3a7bd834-441e-4bd5-84f3-97908896783f_Gatsby_Monogram.png?auto=compress,format and this for the SVG: https://prismic-io.s3.amazonaws.com/previews/596526ad-580f-4764-a224-c19f7c7dd95f_Gatsby_Monogram.svg
As you can see, the PNG already has some default params, as well as the initial ?, whereas the SVG doesn’t. It looks like this is what’s causing it to break when I append my own params.
I’m not sure what the returned URL looked like before, but I assume it included some default params as well, or at least just the trailing ?, as it was working the same for SVGs and PNGs.
I guess it kind of needs to be the same API for all images types as a content editor could upload any type of image, so the templating needs to be able to handle all cases. If I refactor to start my params with a ? then the resulting URL is malformed for PNGs where it’s already included, but like my case now, if I start with an & then the URL is malformed for SVGs.
I didn’t see anything in the docs saying to handle SVGs differently, and this was definitely working before the issue appeared last night, so it seems like a bug was introduced. Could it be on imgix’s side?
I’ve just noticed that the domain where these images are hosted seems to be different for the PNG vs the SVG. The SVG is at https://prismic-io.s3.amazonaws.com and the PNG is at https://images.prismic.io.
I found an old revision of my site and checked the URL of an SVG. The domain was the same as where the current PNGs are hosted: https://images.prismic.io and included the same default query params as the PNGs: ?auto=compress,format. You can still find the image here: https://images.prismic.io/commercial-helios/7d582a06-cbc7-4d9c-b245-39487d650806_perks-04.svg?auto=compress,format&w=550&dpr=2.
So it looks like you’ve changed where SVG images are stored and it’s no longer including the same default params.
It’s probably that SVGs are treated as files rather than pictures. The amazonaws.com domain is used for all file types, and the images.prismic.io is the imgix proxy. Obviously adding size and quality parameters to a SVG file doesn’t make a lot of sense as they aren’t raster graphics.
Here’s a thing saying SVGs aren’t enabled by default on imgix - https://support.imgix.com/hc/en-us/articles/204280985#svg_s
Yes, it’s strange that the svgs are now being delivered from our amazon servers, it’s definitely what’s breaking your images as they don’t support the query params like you’ve seen.
I’m checking with the team if there have been any changes made to our imgix configuration in the past week regarding the enabling of svgs like @marcellothearcane pointed out, that would be logical considering these breaks are recent
Any updates here @Phil?
Hi Sean,
It seems you were right in the assumption that something had changed on our side. The team has disabled the use of SVGs with the Imgix platform because of security vulnerabilities with SVGs, in that they can be injected with JS and because the imgix parameters have no effect on SVGs. So now SVGs are treated as files rather than images and this is why the come from the amazon servers.
The Dev Team thought this change wouldn’t cause any breaks. This is why they didn’t talk to us on the Education Team about this change for us to inform our users, but they didn’t imagine the use case of people currently with SVGs and query params. So in the words of The Captain from Cool Hand Luke “What we’ve got here is failure to communicate”.
I realise this causes a huge headache for you and other users. We are trying to perform checks to see how many users may have been affected. I can only apologise about this and promise that we are putting in place processes so that this doesn’t happen again.
What does this mean for you in practical terms?
For any pages that were using SVGs, which you want to update, you will need either replace your SVGs with another image format or create a workaround in your web application which checks for a ? character in the URL string and does not apply query params based off of that.
I know the sucks and I can only apologise again.
We’re are going to release a communication about this change today and update our documentation. I realise it’s too little, but I we are working hard to make sure something like this doesn’t happen again.
Let me know if you have any further questions about this.
Thanks.
