Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image component can't work with contained non-latin symbols in src prop #19668

Closed
haw0k opened this issue Nov 29, 2020 · 9 comments
Closed

Image component can't work with contained non-latin symbols in src prop #19668

haw0k opened this issue Nov 29, 2020 · 9 comments
Milestone

Comments

@haw0k
Copy link

haw0k commented Nov 29, 2020

Bug report

Describe the bug

If src prop of next/image component contained non-Latin (Cyrillic in the followed example) symbols, GET request to this resource are always throw the 404 error

To Reproduce

test image with cyrillic src prop

Expected behavior

Got the image

Screenshots

Screenshot added

System information

  • OS: [Ubuntu]
  • Browser [chrome, firefox]
  • Version of Next.js: [10.0.3]
  • Version of Node.js: [10.0, 12.0]
  • Deployment: [next build, next start]

Additional context

None
Screen-2020-11-30_00-34-14

@haw0k haw0k added the bug Issue was opened via the bug report template. label Nov 29, 2020
@haw0k haw0k changed the title Image don't work with src contained non-latin symbols Image component can't work with src contained non-latin symbols Nov 29, 2020
@haw0k haw0k changed the title Image component can't work with src contained non-latin symbols Image component can't work with contained non-latin symbols in src prop Nov 29, 2020
@timneutkens timneutkens added kind: bug and removed bug Issue was opened via the bug report template. labels Nov 30, 2020
@timneutkens timneutkens added this to the backlog milestone Nov 30, 2020
@Timer Timer removed this from the backlog milestone Nov 30, 2020
@gelbartj
Copy link
Contributor

gelbartj commented Dec 22, 2020

Unable to reproduce on macOS. I used the exact same filename and directory structure, including using webp, and it works fine for me on Chrome and Firefox.
Screen Shot 2020-12-22 at 3 33 23 PM

@haw0k
Copy link
Author

haw0k commented Dec 23, 2020

Screen Shot 2020-12-22 at 3 33 23 PM

you are using next version 1.0.3?

@gelbartj
Copy link
Contributor

Yes, works on 10.0.3 and 10.0.4.

@haw0k
Copy link
Author

haw0k commented Dec 24, 2020

looks like the problem fixed in 1.0.4 - I can't reproduce this error with version 1.0.4

@Timer Timer added this to the 10.x.x milestone Jan 6, 2021
@emarforio
Copy link

I had the same issue so I did some further investigation and it is not fixed as of 10.0.6. The problem only seem to appear in production (when running npm run build && npm run start) and not in development mode (npm run dev). I have tried this on a couple of devices, (Windows, Ubuntu & Alpine in Docker) and the same result can be seen when switching to production from dev. Files containing only ASCII-characters work fine but files with other characters get a 404 response from the image service. The file can be downloaded fine if opened or linked to the public resource so it seems like the issue lies within the image service.

kodiakhq bot pushed a commit that referenced this issue Aug 2, 2021
fixes #27210
maybe related: #19668

currently, the image optimizer returns 400 when an image url contains non-ascii characters. this pr uri-encodes the `url` query parameter to fix it. also see #27210 (comment)

## Bug

- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`

## Documentation / Examples

- [ ] Make sure the linting passes
@stefanprobst
Copy link
Contributor

@emarforio could you check if you can still reproduce this issue in the current canary version? i think this might have been fixed by #27671

@emarforio
Copy link

@stefanprobst I can confirm that it works with the canary version. I created a repo as a PoC with the two different versions if you want to test it as well: https://github.com/emarforio/nextjs-nonascii-test

@styfle
Copy link
Member

styfle commented Aug 3, 2021

Thanks! I'll close this as a duplicate of #27210 which was fixed in v11.0.2-canary.25

As a reminder, you can try it out canary with yarn add next@canary, thanks!

@styfle styfle closed this as completed Aug 3, 2021
flybayer pushed a commit to blitz-js/next.js that referenced this issue Aug 19, 2021
fixes vercel#27210
maybe related: vercel#19668

currently, the image optimizer returns 400 when an image url contains non-ascii characters. this pr uri-encodes the `url` query parameter to fix it. also see vercel#27210 (comment)

## Bug

- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`

## Documentation / Examples

- [ ] Make sure the linting passes
@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants