My code:
// /src/pages/products/[product].js
export default Product(props) {}
export async function getStaticPaths() {
const productNames = await getProductsName(); // an array of pName, pName is not english
const paths = productNames.map((pName) => ({
params: {product: pName},
}))
return {
paths,
fallback: false,
}
}
export async function getStaticProps(){
// return props
}
// /src/pages/products.js
export default function Products( {product} ) {
return (
<>
<Link href={`/products/${product.name}`}
</>
)
}
export async function getStaticProps(){
// return props
}
When I click the link in “products” page to access “products/青草茶”, I receive this
error:
TypeError - Cannot convert argument to a ByteString because the character at index 15 has a value of 38738 which is greater than 255.
This error only happens when I build my site with nextJs runtime v5.
So I switch back to use runtime v4, this error doesn’t happen, and everything works well.
I wonder is this a bug in nextJs runtime v5?
No. It’s a Node.js limitation. You cannot have a non-ASCII character as request headers. I believe whenever you make that request there is some non-ASCII character being sent as the request header as well causing this issue.
Here’s the documented standard: RFC 9110: HTTP Semantics
Hello! I’m also struggling with this issue after migration to the Netlify Next.js Runtime 5. I don’t see non-encoded ASCII symbols in my headers - everything looks correct. At this stage, I guess it is a Netlify issue, as something has definitely changed in the new runtime in this field.
Could you please help me with understanding what’s going on inside the new runtime? These are my observations:
According to the Netlify logs, the problem happens with this function from the Netlify Runtime. It is an internal function that (presumably) is responsible for generating the cache key for the page in the CDN. As we can see here, it sets the “netlify-cache-tag” header (presumably, this is a response header) when there are some “responseCacheTags” in the request context.
The failing function is called once the Netlify Server Handler. I.e., we can consider that the “netlify-cache-tag” is a response header that we must see for the page request. But we don’t see it for some reason.
There is a “captureCacheTags” function that is responsible for setting the “responseCacheTags” into the request context. Looks like this function uses the page’s route as one of the options for the cache key generation. Why then Netlify doesn’t encode such values as routes that may contain non-ASCII symbols?
That issue is being worked on.
The issue has been solved in the new runtime version. Thanks a lot!