Signed images from S3 no longer working with next/image

[jonahallibone]

EDIT

It seems to only be an issue with certain images (these images worked in the prior version of Next.js and still do). These images that error tend to also be the ones which are frequently loaded because of the pages I use to test my platform. Is there a chance something changed with the caching I need to clear (have already wiped .next a few times to no avail). As far as I can tell, the images which are erroring are the ones I loaded from the external domain prior to upgrading. One's I did not load prior to upgrading still worked. I have tested in multiple browsers and in incognito to make sure there isn't a browser cache issue, and haven't been able to resolve the issue. See comment here

What version of Next.js are you using?

10.1.1

What version of Node.js are you using?

14.16.0

What browser are you using?

Chrome

What operating system are you using?

macOS

How are you deploying your application?

Not currently deployed

Describe the Bug

Previously, pulling signed images from my S3 bucket worked fine with next/image. In fact, if I do a normal <img src="https://url-to-my-bucket/image.jpg?X-Amz-Algorithm...." /> it still works. Since 10.1.1 however, next/image is now reporting The requested resource isn't a valid image. when I pass it the same url which worked fine previously, and still works fine in a native image tag. I have downgraded to verify that it is in fact a new behavior since the latest version of next.js@10.0.x

Expected Behavior

The image would return and display

To Reproduce

Pass next/image a signed url from an Amazon S3 Bucket

[MaksymShokin]

I have same issue on 10.1.2.

[bumpah]

Issue with next/image occurs with all builds on release 10.1.x, working properly with release 10.0.9.

In development mode url like s3-eu-west-1.amazonaws.com gives error hostname "s3-eu-west-1.amazonaws.com" is not configured under images in your `next.config.js` with exact same configuration file that works with version 10.0.9.

[jonahallibone]

I think I partially solved the issue. Turns out S3 returns some images with the Content-Type header as application/octet-stream. Per this line in the new next/image package, it now checks the content-type to see that it contains image/. I'm not sure if this is intentional or not, but I would like to hear the reasoning behind no-longer supporting application/octet streams, or generally not supporting types which aren't explicitly image/

[prarabdhb]

We are also facing the same issue. The images are not signed, but they come Google Cloud Storage, and the content type of the response is application/octet-stream, and therefore images don't render.

[nring]

Same issue here, preventing us from upgrading to 10.1.x. Passing unoptimized={true} will allow images to render, but obviously turns off any worthwhile optimizations.

[sarahkirby]

I had the same issue with serving images from GraphCMS. Adding a loader from the updated docs fixed the issue for me, rather than using the images object in next.config.js.

const myLoader = ({ src, width, quality }) => {
  return `https://media.graphcms.com/${src}?w=${width}&q=${quality || 75}`
}

[prarabdhb]

Is there any update on this? next/image is basically unusable because of this.

[bumpah]

Is there any update on this? next/image is basically unusable because of this.

We have binded to version 10.0.9 for now in production to get around this issue.
Tho, I don't think it should be too difficult to compare diff in Git of 10.0.9 and 10.1.x to look for the change that has caused this issue, but I'm not well knowledged of Next.js codebase.

[shuding]

To add more context: the content type requirement (image/*) was added to fix this issue to make sure that only images can be served. application/octet-stream is the wrong MIME type for images (it's mostly for binary files), but we can probably find a solution for this given the popularity of S3.

[jonahallibone]

@shuding I am curious about not wanting to display anything which isn't image/* only because a native browser image tag will display things regardless of MIME type, as long as it's still an image. Is there a specific reason that next/image is more strict than a native tag?