Repository navigation
Http2 reverses order of headers starting with ":" prefix #38797
Description
- Version: 14.x, 15.x
- Platform: Darwin Kernel Version 18.7.0: Mon Mar 8 22:11:48 PST 2021; root:xnu-4903.278.65~1/RELEASE_X86_64 x86_64
- Subsystem:
What steps will reproduce the bug?
const server = http2
.createSecureServer(sslCerts(), (req, res) => {
const headerOrder = req.rawHeaders.map((x, i) => {
if (i % 2 === 0) return x;
return undefined;
});
// expect headerOrder to be sent order, but will be [':path:',':scheme',':authority',:'method', 'accept-encoding','accept-language']
})
.unref()
.listen(1664);
const client = http2.connect(`https://localhost:1664`);
const headers = {
':method': 'GET',
':authority': `localhost:1664`,
':scheme': 'https',
':path': '/temp1',
'accept-encoding': 'gzip, deflate, br',
'accept-language': 'en-US,en;q=0.9',
};
const h2stream = client.request(headers);How often does it reproduce? Is there a required condition?
Everytime
What is the expected behavior?
Header order matching provided headers
What do you see instead?
Headers are reversed
Additional information
NodeJs is following the spec to insert special http2 headers in the front of the list, but since it traverses headers in order and prepends each one, the prefixed headers will be reversed:
node/lib/internal/http2/util.js
Line 521 in e46c680
Activity
[-]h[/-][+]http2 reverses headers starting with ":" prefix[/+][-]http2 reverses headers starting with ":" prefix[/-][+]Http2 reverses order of headers starting with ":" prefix[/+]jasnell commentedon May 24, 2021
HTTP/2 assigns no significance to the ordering of pseudo-header fields beyond requiring that they appear before the other headers.
blakebyrnes commentedon May 24, 2021
That's a good point @jasnell. It doesn't violate the spec. I just found it to be unexpected behavior that all other http request functions in nodejs maintain the order you send them in. In http2, node will tell you the "headers sent" match the ones you send in, but if you look in wireshark, something different is sent. It seems unintentional - simply a byproduct of the header sorting that's happening. It seems like a minor change to create a second string for prefixed headers that's "appended", and then just concatenating with the rest of the headers to return.
http2: fix pseudo-headers order
http2: fix pseudo-headers order
http2: fix pseudo-headers order
http2: fix pseudo-headers order
http2: fix pseudo-headers order
http2: fix pseudo-headers order
http2: fix pseudo-headers order