René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Cannot CONNECT http2-over-http2 in Node 20.12.0","articleBody":"### Version\n\nv20.12.0\n\n### Platform\n\nLinux 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb  7 14:17:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux\n\n### Subsystem\n\nhttp2\n\n### What steps will reproduce the bug?\n\nTest-suite ready demo:\r\n\r\n```javascript\r\n'use strict';\r\n\r\nconst common = require('../common');\r\nconst assert = require('assert');\r\nconst h2 = require('http2');\r\n\r\nconst server = h2.createServer();\r\n\r\nserver.listen(0, common.mustCall(function() {\r\n  const proxyClient = h2.connect(`http://localhost:${server.address().port}`);\r\n\r\n  const request = proxyClient.request({\r\n    ':method': 'CONNECT',\r\n    ':authority': 'example.com:80'\r\n  });\r\n\r\n  request.on('response', common.mustCall((connectResponse) => {\r\n    assert.strictEqual(connectResponse[':status'], 200);\r\n\r\n    const proxiedClient = h2.connect('http://example.com', {\r\n      createConnection: () => request // Tunnel via first request stream\r\n    });\r\n\r\n    const proxiedRequest = proxiedClient.request();\r\n    proxiedRequest.on('response', common.mustCall((proxiedResponse) => {\r\n      assert.strictEqual(proxiedResponse[':status'], 204);\r\n\r\n      proxiedClient.close();\r\n      proxyClient.close();\r\n      server.close();\r\n    }));\r\n  }));\r\n}));\r\n\r\nserver.once('connect', common.mustCall((req, res) => {\r\n  assert.strictEqual(req.headers[':method'], 'CONNECT');\r\n  res.writeHead(200); // Accept the CONNECT tunnel\r\n\r\n  // Handle this stream as a new 'proxied' connection (pretend to forward\r\n  // but actually just unwrap the tunnel ourselves):\r\n  server.emit('connection', res.stream);\r\n}));\r\n\r\n// Handle the 'proxied' request itself:\r\nserver.once('request', common.mustCall((req, res) => {\r\n  res.writeHead(204);\r\n  res.end();\r\n}));\r\n```\n\n### How often does it reproduce? Is there a required condition?\n\nFails every time in Node v20.12.\r\n\r\nWorks every time in Node v20.11 and previous releases (for a few years, at least)\n\n### What is the expected behavior? Why is that the expected behavior?\n\nIt should be possible to make an HTTP/2 CONNECT request (opening a tunnel to a target server through an HTTP/2 proxy) and then make another HTTP/2 request to the target server.\n\n### What do you see instead?\n\nInstead, creating an HTTP/2 connection on top of an HTTP/2 tunnel fails with:\r\n\r\n```javascript\r\nError [ERR_HTTP2_SOCKET_BOUND]: The socket is already bound to an Http2Session\r\n    at new Http2Session (node:internal/http2/core:1238:13)\r\n    at new ServerHttp2Session (node:internal/http2/core:1640:5)\r\n    at Http2Server.connectionListener (node:internal/http2/core:3102:19)\r\n    at Http2Server.emit (node:events:518:28)\r\n    at Http2Server.\u003canonymous> (/home/tim/Dropbox/programming/javascript/node/test/parallel/test-http2-client-proxy-over-http2.js:41:10)\r\n    at Http2Server.\u003canonymous> (/home/tim/Dropbox/programming/javascript/node/test/common/index.js:473:15)\r\n    at Object.onceWrapper (node:events:633:26)\r\n    at Http2Server.emit (node:events:518:28)\r\n    at Http2Server.onServerStream (node:internal/http2/compat:956:17)\r\n    at Http2Server.emit (node:events:518:28) {\r\n  code: 'ERR_HTTP2_SOCKET_BOUND'\r\n}\r\n```\n\n### Additional information\n\nI'm fairly sure I know the issue here: `kSession` is used in the HTTP/2 code as a single symbol with two meanings:\r\n\r\n* On sockets, marking them as being owned by an HTTP/2 session (i.e. there is a session currently running within this socket)\r\n* On HTTP/2 streams, providing access to the HTTP/2 session that contains them (i.e. this stream is running within that session)\r\n\r\nIn this case, these two meanings mix: the CONNECT stream should be within an HTTP/2 session (the initial connection) _and_ should act as a socket and contain an HTTP/2 session. That conflict is why this blows up.\r\n\r\nThis didn't happen in the past because the inner stream uses a JSStreamSocket to handle this, and kSession wasn't passed through that wrapper, so the JSS and the inner H2 stream had independent kSession values. That changed in https://github.com/nodejs/node/commit/c50524a9fc19cd2fe6e61bb7f8ad22685024842b#diff-8dd7127678f00bf090a030256bad7ae645834f7100e54154b4fc81c8cbe9c3fc, which (reasonably I think) exposed the 'real' kSession through that wrapper.\r\n\r\nI think the solution here is two split these two use cases, and track the 'socket-in-use-by' and 'stream-powered-by' state under separate keys, so a single H2 stream can have both. I'm going to keep digging and hopefully open a PR for this within a day or two, but if anybody has any context on that in the meantime and whether this is going to work or whether there's a good reason the two are the same, that would be very interesting.","author":{"url":"https://github.com/pimterry","@type":"Person","name":"pimterry"},"datePublished":"2024-04-03T11:50:38Z","url":"https://github.com/nodejs/node/issues/52344"}