You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linux 6.2.0-39-generic 40-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:18:00 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
http2
What steps will reproduce the bug?
consthttp2=require('http2');constserver=http2.createServer((req,res)=>{console.log('Got request');// This would work as expected:// res.writeHead(200, {// 'set-cookie': ['a', 'b']// });// This does not:res.writeHead(200,['set-cookie','a','set-cookie','b']);res.end('Done');});server.listen(9000,()=>{constclient=http2.connect(`http://localhost:${server.address().port}`);constreq=client.request({':path': '/'});req.on('response',(res)=>{console.log('Got response',res);});});
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
The response should show two set-cookie values
What do you see instead?
The response shows only the 2nd value, losing the first:
This is part of the HTTP/1 compat API for HTTP/2. This works correctly with HTTP/1, but here although the compat layer attempts to handle raw headers, it doesn't quite do so correctly for trickier cases like this. It seems that the logic used in the compat API in #42901 (a fix for a different compat API issue) didn't take duplicate headers into account, and so the last matching header overrides all others.
I'll open up a fix for this shortly, watch this space.
The text was updated successfully, but these errors were encountered:
pimterry
changed the title
HTTP/2 compat API drops duplicate headers with raw headers are provided
HTTP/2 compat API drops duplicate headers when raw headers are provided
Jan 9, 2024
Version
v21.4.0, v20.8.0
Platform
Linux 6.2.0-39-generic 40-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:18:00 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
http2
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
The response should show two
set-cookie
valuesWhat do you see instead?
The response shows only the 2nd value, losing the first:
Additional information
This is part of the HTTP/1 compat API for HTTP/2. This works correctly with HTTP/1, but here although the compat layer attempts to handle raw headers, it doesn't quite do so correctly for trickier cases like this. It seems that the logic used in the compat API in #42901 (a fix for a different compat API issue) didn't take duplicate headers into account, and so the last matching header overrides all others.
I'll open up a fix for this shortly, watch this space.
The text was updated successfully, but these errors were encountered: