Replies: 11 comments 14 replies
-
|
Wow that's wild... The return `${normalizePathTrailingSlash(config.path)}?url=${encodeURIComponent(
src
)}&w=${width}&q=${quality || 75}`Why on earth would the ampersand pop up.... I think that line has changed very little over the past 2 years. I am confused with this one. Do you have a custom loader? |
Beta Was this translation helpful? Give feedback.
-
|
Its usually the same group of images that return HTTP 400. |
Beta Was this translation helpful? Give feedback.
-
|
Where did you pick on this log, or is it from the DOM (src in the img element rendered): This is very strange. I am trying to reproduce it but cannot hit any reproduction. Are you seeing this in any browser in particular? |
Beta Was this translation helpful? Give feedback.
-
|
Its from the cloud run log events |
Beta Was this translation helpful? Give feedback.
-
|
More information , its related to traffic that arrived from Facebook app |
Beta Was this translation helpful? Give feedback.
-
|
Yeah those added extra user agents are from FB on app browser. Have you been able to try and reliably reproduce this? I'll give it a go this afternoon. I wonder if there's somehow a utm or other sort of tracking system messing up with the url. Or if this is happening in specific devices/browser versions. |
Beta Was this translation helpful? Give feedback.
-
|
@miko-code @icyJoseph Hi there. Is there any updates? @miko-code How did you solve this problem? |
Beta Was this translation helpful? Give feedback.
-
|
Having the same issue on a site I'm working on. Again, it's only certain versions of the Facebook app browser. It looks like the Facebook browser is somehow re-writing / encoding the image URLs? Any thoughts on a workaround or fix for this behaviour? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this is related, but I have an issue using the priority prop in next/image. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Guys, I am also facing this same issue @HelaGone faced, On our site during Google Curls for the image goes 404 because of the "w" parameter (width) is required error Note:- I am not facing this issue on the actual frontend, It's working fine. Has anyone here faced this issue and how to fix it? |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I am also facing this issue still. Did anyone find a solution on this yet? Seeing lots of 400s.
|
Beta Was this translation helpful? Give feedback.
-
|
We are also seeing this same issue with: Should we ever be seeing After chatting it out with Claude Sonnet.... -- From Claude Sonnet -- The Here's the correct sequence that should happen:
The presence of
This is definitely a bug in Next.js's Image component implementation. The component should:
|
Beta Was this translation helpful? Give feedback.
-
|
I am just loop the conversation here [https://github.com//issues/68998] @iDVB Hope the above conversation is helpful You are right they are not fully encoded the url
Not yet resolved? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @vigneshMuthumariyappan , Further Claude Sonnet convo thoughts --- When you pass a string value to an HTML attribute in React/JSX, React's default HTML escaping kicks in and converts special characters to HTML entities. This is why we see This explains why:
The fix in Next.js would need to:
|
Beta Was this translation helpful? Give feedback.
-
|
Do you have a link to a page that loads an image with the HTML entity? |
Beta Was this translation helpful? Give feedback.
-
|
@icyJoseph It sounds like this is React's built-in XSS protection at work - it automatically escapes special characters in HTML attribute values to prevent injection attacks. When React sees a & in an attribute value, it converts it to & for safety. We have confirmed that you can actually test this with a simple React example: This will render as: So to see a link to a page that loads an image with the HTML entity, you just need a link to any site that uses react and that has an image with at least a single querystring. Here is one: dev tools element: ( view source: ( |
Beta Was this translation helpful? Give feedback.
-
|
Alright, I see, so react-dom SSR tooling, uses It is not just like, attributes, take for instance: <span>&</span>The server would send, So when React collects the VDOM for a server tree, and makes a simple HTML string out of it, those 5 html entities, get escaped, and then your HTML, as served by the server, has the escaped entities. Now the thing is... browsers decode these automatically. It is not the only thing where browsers change the incoming HTML, some invalid nesting, for example nested p tags, are re-interpreted, etc... So, it'd look like those bots and such, should also process those character references |
Beta Was this translation helpful? Give feedback.
-
|
@icyJoseph Sounds like you have a better handle on the issue then I. |
Beta Was this translation helpful? Give feedback.
-
|
Do you have logs on user agents arriving on the request? |
Beta Was this translation helpful? Give feedback.
-
|
user agents I have! |
Beta Was this translation helpful? Give feedback.
-
|
🤔 but how could we reproduce this feature? It looks like it has to be a bot/crawler that, gets the site HTML, and straight up parses the string, without fixing the character references. |
Beta Was this translation helpful? Give feedback.
-
|
@icyJoseph Simply, Why we shouldn't encode full url instead of concat &w={..} as mentioned in the below image 🤔? Is there cause any issue?
|
Beta Was this translation helpful? Give feedback.
-
|
Those are query parameters, the url is encoded so that it can be transported as a query parameter as well. The issue that has been pointed out, is that, when doing the SSR string, ReactDOM invokes a function that replaces 5 character references, that is when it finds |
Beta Was this translation helpful? Give feedback.
-
We are using next 12.0.4 and we have a weird bug in our production
Sometimes images URL is generated with addition ampersand and causing URL to be malformed
that causing a HTTP 400 error because W parameter cant be parsed correctly.
The most weird thing is that its happen randomly for some of the traffic.
Beta Was this translation helpful? Give feedback.
All reactions