fix: get set-cookie header with credentials: include

[KhafraDev]

Fixes #1262

When credentials is equal to include, the set-cookie header(s) should not be stripped.

[codecov-commenter]

Codecov Report

Merging #1454 (c2020a9) into main (3b5353a) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1454   +/-   ##
=======================================
  Coverage   94.37%   94.37%           
=======================================
  Files          49       49           
  Lines        4231     4231           
=======================================
  Hits         3993     3993           
  Misses        238      238           

Impacted Files	Coverage Δ
lib/fetch/index.js	80.77% <100.00%> (ø)
lib/fetch/response.js	87.83% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b5353a...c2020a9. Read the comment docs.

[mcollina]

lgtm

[ronag]

IMHO this is wrong and does not follow the spec.

Probably related:

undici/lib/fetch/index.js

Lines 1806 to 1811 in 5478cdd

	// 3. If includeCredentials is true and the user agent is not configured
	// to block cookies for request (see section 7 of [COOKIES]), then run the
	// "set-cookie-string" parsing algorithm (see section 5.2 of [COOKIES]) on
	// the value of each header whose name is a byte-case-insensitive match for
	// `Set-Cookie` in response’s header list, if any, and request’s current URL.
	// TODO

I think this landed too early and would prefer we properly investigate and follow the spec. This feels more like a hack.

[ronag]

@KhafraDev

[mcollina]

Ok I'll push a revert, seemed ok at first look.

[mcollina]

revert pushed.

[KhafraDev]

@ronag I tried implementing it but it wouldn't solve the use case. It only states to parse the cookies. In the rfc itself, it doesn't make any mention of headers/disposing of "invalid" cookies.

When the user agent finishes parsing the set-cookie-string, the user
   agent is said to "receive a cookie" from the request-uri with name
   cookie-name, value cookie-value, and attributes cookie-attribute-
   list.  (See [Section 5.3](https://datatracker.ietf.org/doc/html/rfc6265#section-5.3) for additional requirements triggered by
   receiving a cookie.)

So I deemed it a bug with the proxy as it was incorrectly filtering out set-cookie/set-cookie2 headers when credentials: include was set.

I'd like to add that the set-cookie header can still exist in the private header map, but the proxy will always see that it's a forbidden header name and return null by default.

[ronag]

The logic added here is not part of the spec. So either we are doing something differently (not good) or there is a bug in the spec.

The third option is that we have not implemented something in the spec or done it incorrectly. However this PR does not address that.

[KhafraDev]

Yep, the spec doesn't allow set-cookie headers by design. However, this comment shows how just about every other non-browser platform allows this. Similar alterations from the spec regarding headers has been done with the redirect: "manual" change.

(note how the cookie(s) are being received because of the warning, but they aren't available to the user)

[ronag]

Can we raise this to wintercg?

[ronag]

What does deno and cloudflare do?

[ronag]

This conversation is happening in two places now. Maybe continue in #1262.