fix: Remove the default connection close header. #1736
Conversation
Instead, we rely on the underlying http implementation in Node.js to handle this, as per the documentation at https://nodejs.org/api/http.html#new-agentoptions This fixes node-fetch#1735 and likely replaces node-fetch#1473 The original change introducing this provided no clear motivation for the override, and the implementation has since been changed to disable this header when an agent is provided, so I think there is sufficient evidence that removing this is the correct behaviour. node-fetch@af21ae6 node-fetch@7f68577
|
Thanks @LinusU 👍 Is there anything more I can do to help get this merged? Would it help if I raised a separate PR to backport this to the 2.x branch now? |
|
@jimmywarting the failing tests doesn't seem related to this PR, they fail for me locally as well. Could you take a look and possible merge and release? |
|
@dhedey sorry for the delay, nothing more should be required from your side! |
|
Hi there. We are end users through |
|
🎉 This PR is included in version 3.3.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Thank you @jimmywarting and @dhedey 🎉 |
|
Awesome work guys! It has been really insightful to follow the discussions here and on the node issue. I am wondering if you also plan to backport this to 2.x branch, this would be really appreciated. I guess with more people updating to node 20 it is also quite important to do. |
|
Dont know about backporting to v2 is really necessary. It is mostly frezed and dose not really get any new feature updates. Only critical bug fixes and security related stuff. Cjs user can still import esm version if they use async import instead. const fetch = (...args) => import('node-fetch').then(({default: fetch}) => fetch(...args)) Or update to a node version that has fetch built in |
|
I understand your concerns and might be good to not touch v2, assuming those users are on older node version anyways. The problem is rather with cross-fetch not updating to node-fetch v3, but this has been proposed a while ago already lquixada/cross-fetch#146. |
|
Can I start this by saying - I've used node-fetch a lot over the years, and really appreciate the hard work and stewardship of you and the other contributors to this project 👍. This is a critical bug in my opinion, simply breaking many integrations when using I believe this change is low-risk, for a couple of reasons:
I'm happy to put in that PR to version 2 if that's a help. To add some flavour regarding attention to version 2 - the reality is that:
It's worth noting that I tried just using Don't get me wrong, I'm not trying to criticise v3 at all! But I just wanted to emphasise, that the main user base is still on v2, and in my opinion, almost certainly will always be - because only v2 really captures the USP of "why do I want to use
And v3 doesn't work so well for either (A) or (B), so most projects are still running v2 (or would migrate off to |
Instead, we rely on the underlying http implementation in Node.js to handle this, as per the documentation at https://nodejs.org/api/http.html#new-agentoptions This fixes node-fetch#1735 and likely replaces node-fetch#1473 The original change introducing this provided no clear motivation for the override, and the implementation has since been changed to disable this header when an agent is provided, so I think there is sufficient evidence that removing this is the correct behaviour. node-fetch@af21ae6 node-fetch@7f68577 This commit is backported to the v2 branch from node-fetch#1736 against v3.
|
If you feel like backporting it then go for it |
|
Fantastic, thanks @jimmywarting - Appreciate your support on this. I've raised the PR here: #1765 - over to you to approve and release. Thanks again! |
Instead, we rely on the underlying http implementation in Node.js to handle this, as per the documentation at https://nodejs.org/api/http.html#new-agentoptions This fixes #1735 and likely replaces #1473 The original change introducing this provided no clear motivation for the override, and the implementation has since been changed to disable this header when an agent is provided, so I think there is sufficient evidence that removing this is the correct behaviour. af21ae6 7f68577 This commit is backported to the v2 branch from #1736 against v3.
Purpose
This fixes #1735 and likely replaces #1473.
Changes
Removes the behaviour to add a
Connection: closeheader. This was causing issues in Node.js 19+ (see #1735), but possibly subtle issues in earlier Node.js too. Note that we still expect some users to usenode-fetchin Node.js 19+ because enabling fetch requires an--experimental-fetchcommand line parameter passed to Node.js and some users (such as people consuming my library which requires afetchimplementation) require it.Instead, we rely on the underlying http implementation in Node.js to handle this, as per the documentation at
https://nodejs.org/api/http.html#new-agentoptions
The original change introducing this provided no clear motivation for providing the header, and the implementation has since been changed to disable this header when an agent is provided, so I think there is sufficient evidence that removing this header is the correct behaviour.
If this change is accepted, I'm happy to back-port this into the 2.x branch, as I know some users of my library use 2.x because they can't use ESM.
Additional information
See #1735 for background.
(I didn't add unit tests because the behaviour now depends the presence of the header now depends on the default http agent behaviour, and therefore on the Node.js version being used and I didn't want to introduce that dependency into the tests)
keep-aliveby default forConnectionheader. #1473