-
-
Notifications
You must be signed in to change notification settings - Fork 76
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
Header encoding changes, leading to ERR_INVALID_CHAR
#287
Comments
Ouch! have you got a full stack trace? Would you like to send a PR? |
Stack trace:
As for a PR, I have no idea where to start. 😅 I'm unsure if the bug is here, in Fastify core, or even in Node core itself. |
HTTP Headers are not supposed to contain UTF-8 characters. There are two bugs:
|
This issue fastify/fastify#3808 just pop up in my memory when seeing non-ASCII string in header.
According to the research from that issue nodejs/node#42579 I assume we are not bypass anything in
We need to think why only chaining will set |
I still see it as a upstream bug from It should throw no matter the header |
@climba03003 could you open an issue on Node.js describing the problem? |
Ah, based on the links in the Node issue, adding Note that |
When the When there is a |
Should we fork content-disposition? |
|
const {transcode: bufferTranscode} = require('node:buffer');
const utf8Buffer = Buffer.from('å');
const latin1Buffer = bufferTranscode(utf8Buffer, 'utf8', 'latin1');
console.log(Buffer.compare(utf8Buffer, latin1Buffer)); // logs -1 |
It still confuse me why the first comparison is const contentDeposition = require('content-disposition')
const http = require('http')
const { request } = require('undici')
const header = contentDeposition('år.pdf') // C3A5
http.createServer(function(_, response) {
response.writeHead(200, {
'content-length': 2,
'content-disposition': header
})
response.end('OK')
}).listen({ port: 6666 })
http.createServer(async function(_, response) {
const { statusCode, headers, body } = await request('http://localhost:6666', {
method: "GET"
})
console.log(headers)
console.log(headers['content-disposition'] === header) // true C3A5
delete headers['transfer-encoding']
response.writeHead(statusCode, headers)
body.pipe(response)
}).listen({ port: 7777 })
http.createServer(async function(_, response) {
const { statusCode, headers, body } = await request('http://localhost:7777', {
method: "GET"
})
console.log(headers)
console.log(headers['content-disposition'] === header) // false EFBFBD
delete headers['transfer-encoding']
response.writeHead(statusCode, headers)
body.pipe(response)
}).listen({ port: 8888 }) |
When fetching
I think this is just bad printing by $ http http://localhost:6666
HTTP/1.1 200 OK
Connection: keep-alive
Date: Mon, 30 Jan 2023 10:44:26 GMT
Keep-Alive: timeout=5
content-disposition: attachment; filename="Ã¥r.pdf"
content-length: 2
OK
$http http://localhost:7777
HTTP/1.1 200 OK
connection: keep-alive
content-disposition: attachment; filename="år.pdf"
content-length: 2
date: Mon, 30 Jan 2023 10:44:35 GMT
keep-alive: timeout=5
OK
So I do think there's some encoding issue here, and I do think |
If conversion is happened. |
I see the problem, whenever you are not writing So, The problematic behavior actually cause by The problem exist because
|
Can confirm that this is fixed by nodejs/undici#1911 (without #289 applied) 🎉 |
Prerequisites
Fastify version
4.12.0
Plugin version
8.3.1
Node.js version
16.19.0
Operating system
macOS
Operating system version (i.e. 20.04, 11.3, 10)
13.1
Description
When a header is set using a character like
å
(Norwegian character) its encoding gets messed up. A fastify server serving it serializes correctly, but ifreply-from
is used, the encoding changes. If another server withreply-from
is chained, the app crashes withTypeError [ERR_INVALID_CHAR]: Invalid character in header content ["content-disposition"]
.Steps to Reproduce
Expected Behavior
The header should be correctly encoded and decoded (i.e.
7777
and8888
should have the same result as6666
).If that's not possible I expect the first server to complain when the header is added.
The text was updated successfully, but these errors were encountered: