cookie no longer able to be set in the Headers API as of v5.2.0

[erunion]

Bug Description

Upgrading Node from 18.1 to 18.2 we are no longer able to set the cookie header in the Headers API.

Seems this is a result of #1337

Reproducible By

const headers = new Headers();
headers.append('cookie', 'bar=baz; foo=bar');

fetch('https://httpbin.org/cookies', {
  headers,
})
  .then(res => res.json())
  .then(console.log);

Running the above code on Node 18.1:

{ cookies: { bar: 'baz', foo: 'bar' } }

On Node 18.2 (and undidi 5.2):

{ cookies: {} }

Curiously if I don't use the Headers API and set the cookie header directly it works:

fetch('https://httpbin.org/cookies', {
  headers: {
    cookie: 'bar=baz; foo=bar',
  },
})
  .then(res => res.json())
  .then(console.log);

// { cookies: { bar: 'baz', foo: 'bar' } }

Expected Behavior

Would expect to be able to still set the cookie header because we can't use document.cookie like you can use in browser environments.

Environment

• OSX 11.6
• Node 18.1 and Node 18.2 using nvm

[KhafraDev]

This is expected - undici follows the fetch spec and not how other platforms behave. The fetch spec tells implementations to filter out set-cookie and set-cookie2 headers, so that's what occurs.

[erunion]

Ok and looks like undici doesn't support includeCredentials right now so it's unfortunate that this code of mine is broken until that's added.

[KhafraDev]

That section of the code deals with setting cookies in a per-origin browser cookie jar, not getting/setting/sending set-cookie headers. See #1262

[aeharding]

Hello! I'm confused. I was using nodejs v18.0 fetch and I could get the Set-Cookie header just fine.

However now I cannot when I upgraded to nodejs v18.2. I see it when doing a console.log() of response.headers, but response.headers.get('set-cookie') doesn't work.

I understand that that's the fetch API standard, but that standards seems like it was designed for a browser, and not Node.

(BTW, my use case is proxying a CouchDB POST to _session.)

So I guess the fetch API is simply not compatible with my use case and I must use a third party library?

[KhafraDev]

I understand that that's the fetch API standard, but that standards seems like it was designed for a browser, and not Node

Yes, you are entirely correct. The fetch spec was developed with browsers in mind - not so much a server environment. This causes a few problems with deciding how features should behave when the spec is subpar for a node.js use-case. Some decisions were made to branch away from the spec, however, those decisions were made before the creation of the WinterCG so now it has been decided to wait for a cross-platform solution/"spec", rather than introducing our own.

See: #1262 (comment) Re-reading it, if you put in the work, it seems as though a PR will be accepted. Unsure of that though, you can always make a PR for yourself, or wait for me to do it 😛.

So I guess the fetch API is simply not compatible with my use case and I must use a third party library?

Until a decision is made, unfortunately you will. I checked undici.request, but that also does not accept sending set-cookie headers. 😦

[aeharding]

Thanks for the quick response! That sounds good.

In case anyone else is reading and has the same issue, node-fetch allows accessing the Set-Cookie header on the response. A workaround with a similar API in the meantime. :)

https://www.npmjs.com/package/node-fetch

[mcollina]

I checked undici.request, but that also does not accept sending set-cookie headers.

Could you open a fresh issue? That should definitely be possible. BTW, I think set-cookie is received, not sent.

[KhafraDev]

You can actually send set-cookie headers with undici.request - the example was wrong in the original post.

import { request } from 'undici'
import { createServer } from 'http';
import { once } from 'events';

const server = createServer((req, res) => {
  console.log(req.headers['set-cookie'])
  res.end('goodbye')
}).listen(0)

await once(server, 'listening')

await request(`http:https://localhost:${server.address().port}`, {
  headers: {
    'set-cookie': 'bar=baz; foo=bar'
  }
})

server.close()

Outputs:

[ 'bar=baz; foo=bar' ]

@aeharding if you don't mind switching from fetch, undici.request has a great api with less restrictions.

[wmertens]

I'm seeing something related in 5.2.0 and 5.3.0 - I was using Headers to pass the headers, and with older versions that allowed me to authenticate but it broke other things.

I upgraded to 5.2 and I could no longer authenticate. However, when I change the headers to a plain object with Object.fromEntries(headers.entries()), it works.

So there is still an issue with Headers and cookies, somehow.

[issuefiler]

@erunion: Ok and looks like undici doesn't support includeCredentials right now so it's unfortunate that this code of mine is broken until that's added.

@KhafraDev: That section of the code deals with setting cookies in a per-origin browser cookie jar, not getting/setting/sending set-cookie headers. See #1262

---

Okay, hold on.

Do you understand what set-cookie is? If you don’t, this is my excerpt from MDN for you:

The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.

How would you set cookies according to the set-header if you’re unable to read it? The browser does it automatically; does Node.js do it?

---

In the first place, what’s the point of bringing unnecessary constraints to this? What’s the point of being so obsessed with all the security features that are only meaningful to web browsers? “Because the spec says so?” The specification is intended for browsers. And what is this, a headless browser? It is not feasible at all to imitate what the browser does on Node.js to begin with.

Look, this is globalThis.fetch on Node.js. Stop saying “We just do what the spec says, problem?” and stop promoting third-party package, Undici, that does the same thing as fetch. Why are you guys making the first-ever dependency-less built-in Promise-based requestor function of Node.js so pointless? If I need to use other packages on NPM to make requests, then what is the point of globalThis.fetch?

Node.js’ fetch still can be compatible with the browser’s, without those unnecessary constraints for browsers.

Please, double please, reconsider the direction of globalThis.fetch’s implementation.

[mcollina]

I have opened wintercg/fetch#7 to discuss with the WinterCG team.

[benjamingr]

Hey, @issuefiler.

Node landed an experimental implementation of fetch given some semantics people think make sense. Part of the fact it's experimental is because we are explicitly looking for feedback and to see how people think fetch should behave.

Please be mindful of how you phrase yourself. Your comment comes off (to me) as harsh whereas this sort of feedback (the technical bits) are welcome. There are many people using Node.js with different requirements, preferences and ideas about what APIs should do and Node.js is happy to listen to those users in good faith and reconsider API choices.

Your comment makes this a bit hard given the tone. If you want effective discourse I recommend you consider a different approach/tone towards the volunteers working on new features for the platform.