next.js: Signed images from S3 no longer working with next/image

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

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 12
  • Comments: 21 (4 by maintainers)

Commits related to this issue

Most upvoted comments

The fix is available in next@11.0.2-canary.4, thanks!

In an effort to keep some momentum on this ticket, I created some changes that pass all tests and fix rendering for images from S3 in my demo app. It’s up on my fork here. I’m not sure how to mock Next’s Content-Type in the response, otherwise I’d have taken a stab at an additional integration test. I’d love some help polishing this up to open a PR.

Edit: PR Opened https://github.com/vercel/next.js/pull/24583

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.

I was wondering as well if relying solely on http-headers is really the best way to handle this kind of a use case.

Next.js anyhow needs to fetch the original image for optimizations so why not read the file-extension and based on that decide if Next.js supports that specific filetype for image optimizations, and if image is not optimizable just return original Image from the response and only if file-extension is not supported image type at all return 400 error code.

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.