René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"fetch() and http.request() disagree when a lower-cased proxy env var is empty","articleBody":"### Version\n\nv27.0.0-pre (main, 976a36a5b6c)\n\n### Platform\n\n```text\nLinux 6.14.0-37-generic x64\n```\n\n### Subsystem\n\nhttp\n\n### What steps will reproduce the bug?\n\nRun the script below with a build that has built-in proxy support.\n\nIt starts a proxy and an origin server, then launches a child process that sends one `http.request()` and one `fetch()` using the same proxy environment. The script reports whether each request went through the proxy.\n\n```js\n'use strict';\n\nconst http = require('http');\nconst { spawn } = require('child_process');\nconst { once } = require('events');\n\nconst seen = [];\n\nconst proxy = http.createServer((req, res) => {\n  seen.push(req.url);\n\n  const url = new URL(req.url);\n  http.request({\n    hostname: url.hostname,\n    port: url.port,\n    path: url.pathname,\n  })\n    .on('response', (proxyRes) => proxyRes.pipe(res))\n    .on('error', () => res.end())\n    .end();\n});\n\nconst server = http.createServer((req, res) => res.end('Hello world'));\n\nconst child = `\nconst url = process.env.REQUEST_URL;\n\nrequire('http').get(url + 'request', (res) => {\n  res.resume();\n\n  res.on('end', () => {\n    fetch(url + 'fetch')\n      .then((r) => r.text())\n      .then(\n        () => process.exit(0),\n        () => process.exit(0),\n      );\n  });\n});\n`;\n\n(async () => {\n  proxy.listen(0);\n  server.listen(0);\n\n  await Promise.all([\n    once(proxy, 'listening'),\n    once(server, 'listening'),\n  ]);\n\n  const PROXY = `http://localhost:${proxy.address().port}`;\n  const REQUEST_URL = `http://localhost:${server.address().port}/`;\n\n  const cases = [\n    ['HTTP_PROXY only               ', {\n      HTTP_PROXY: PROXY,\n    }],\n    [\"http_proxy='' HTTP_PROXY=proxy\", {\n      http_proxy: '',\n      HTTP_PROXY: PROXY,\n    }],\n    [\"no_proxy='' NO_PROXY='*'      \", {\n      HTTP_PROXY: PROXY,\n      no_proxy: '',\n      NO_PROXY: '*',\n    }],\n  ];\n\n  for (const [name, env] of cases) {\n    seen.length = 0;\n\n    const childEnv = {\n      ...process.env,\n      NODE_USE_ENV_PROXY: '1',\n      REQUEST_URL,\n    };\n\n    // Avoid inheriting proxy configuration from the machine running\n    // the reproduction.\n    for (const key of [\n      'http_proxy',\n      'HTTP_PROXY',\n      'https_proxy',\n      'HTTPS_PROXY',\n      'no_proxy',\n      'NO_PROXY',\n    ]) {\n      delete childEnv[key];\n    }\n\n    Object.assign(childEnv, env);\n\n    const cp = spawn(process.execPath, ['-e', child], {\n      env: childEnv,\n      stdio: 'ignore',\n    });\n\n    await once(cp, 'exit');\n\n    const via = (tag) =>\n      seen.some((url) => url.endsWith('/' + tag)) ? 'proxy ' : 'direct';\n\n    console.log(\n      `${name}  http.request: ${via('request')}  fetch: ${via('fetch')}`,\n    );\n  }\n\n  proxy.close();\n  server.close();\n})();\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery run.\n\nIt requires `NODE_USE_ENV_PROXY=1` (or `--use-env-proxy`) and a lower-cased proxy variable set to the empty string while its upper-cased counterpart is set.\n\nThis does not apply to Windows, where environment variable names are case-insensitive.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`fetch()` and `http.request()` should interpret the same proxy environment consistently when built-in proxy support is enabled.\n\nWhich interpretation of an empty lower-cased value should be used is a separate question. There are at least two existing behaviors in the ecosystem:\n\n* curl treats an empty lower-cased value as unset and can fall back to the upper-cased variable.\n* Python's `urllib.getproxies_environment()` treats an empty lower-cased value as an override that removes the upper-cased value.\n\nNode.js currently implements both interpretations at once, depending on which client is used.\n\nThe HTTP documentation describes the lower-cased variables as, for example:\n\n> Same as `HTTP_PROXY`. If both are set, `http_proxy` takes precedence.\n\nAn explicitly present empty string makes the intended behavior here ambiguous.\n\n### What do you see instead?\n\n```\nHTTP_PROXY only                 http.request: proxy   fetch: proxy\nhttp_proxy='' HTTP_PROXY=proxy  http.request: proxy   fetch: direct\nno_proxy='' NO_PROXY='*'        http.request: direct  fetch: proxy\n```\n\nThe last two cases disagree, in opposite directions.\n\n### Additional information\n\nThe built-in HTTP implementation uses `||` when selecting between lower- and upper-cased variables:\n\n[`lib/internal/http.js#L206`](https://github.com/nodejs/node/blob/976a36a5b6c/lib/internal/http.js#L206):\n\n```js\nenv.http_proxy || env.HTTP_PROXY\n```\n\n[`lib/internal/http.js#L237`](https://github.com/nodejs/node/blob/976a36a5b6c/lib/internal/http.js#L237):\n\n```js\nenv.no_proxy || env.NO_PROXY\n```\n\nTherefore an empty lower-cased value is falsy and the upper-cased value wins.\n\nUndici's `EnvHttpProxyAgent`, used by `fetch()` through `setupHttpProxy()`, uses nullish coalescing instead:\n\n[`deps/undici/src/lib/dispatcher/env-http-proxy-agent.js#L26`](https://github.com/nodejs/node/blob/976a36a5b6c/deps/undici/src/lib/dispatcher/env-http-proxy-agent.js#L26):\n\n```js\nhttpProxy ?? process.env.http_proxy ?? process.env.HTTP_PROXY\n```\n\nand for `NO_PROXY`:\n\n[`deps/undici/src/lib/dispatcher/env-http-proxy-agent.js#L171`](https://github.com/nodejs/node/blob/976a36a5b6c/deps/undici/src/lib/dispatcher/env-http-proxy-agent.js#L171):\n\n```js\nprocess.env.no_proxy ?? process.env.NO_PROXY ?? ''\n```\n\nTherefore an empty lower-cased value wins on the Undici side.\n\nThe built-in behavior has been present since 036b1fd66d8 added proxy support to `http.request()` in v25.0.0. The reproduction above was only run against the stated build of `main`.\n\nThis appears related to #65616, where `NO_PROXY` matching also differs between `fetch()` and `http.request()`.\n\nIt also relates directly to the still-open item in #57872:\n\n> Share code between the fetch and the http(s) builtin implementation (e.g. env var parsing & matching)\n\nA regression test can demonstrate the inconsistency without deciding which interpretation is correct:\n\n```js\nconst viaRequest = await usesProxy('request', env);\nconst viaFetch = await usesProxy('fetch', env);\n\nassert.strictEqual(viaFetch, viaRequest);\n```\n\nOn current behavior, the empty `http_proxy` and empty `no_proxy` cases fail.\n\nI would be happy to send a PR once it is decided which interpretation built-in proxy support should use consistently.\n\nIf the built-in HTTP behavior is preferred, the corresponding Undici behavior would need to be aligned upstream. If the Undici behavior is preferred, the `||` selections in `lib/internal/http.js` can be changed accordingly. The documentation should then specify how empty values are interpreted.\n\nRefs: [https://github.com/nodejs/node/issues/57872](https://github.com/nodejs/node/issues/57872)","author":{"url":"https://github.com/christianaurichzm","@type":"Person","name":"christianaurichzm"},"datePublished":"2026-09-22T10:29:03Z","url":"https://github.com/nodejs/node/issues/66202"}