Bug 251194 – [fetch] Implement `Headers.prototype.getSetCookie`

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Andreu Botella]

Spec PR: https://github.com/whatwg/fetch/pull/1346
Test PR: https://github.com/web-platform-tests/wpt/pull/31442

The proposed `getSetCookie()` method of the Headers class allows getting a list of the values of the `Set-Cookie` header in the header list. This was not possible before, since the `get()` method would combine the values by joining them with comma and whitespace, which is valid per the HTTP spec, but clashes with Set-Cookie syntax.

The spec change that introduces this method also changes the iteration behavior for Headers to have each Set-Cookie header show up in the iteration, rather than having them combined.

The fetch spec's `Request` and `Response` classes don't allow setting the `Set-Cookie` header, and `fetch` will remove that header from the returned `Response`. This change to the spec does not change this. It only makes it so a user-created `Headers` class can deal with `Set-Cookie` headers in an easier way, and enables compatibility with server-side runtimes which allow these headers.

[Andreu Botella]

By the way, I am working on a patch to implement this method. The main thing that makes this hard in WebKit is that the Headers interface is backed by an `HTTPHeaderMap`, which already combines all headers with the same name. Any patch would therefore have to add support for multiple `Set-Cookie` header values to `HTTPHeaderMap`.

Since `HTTPHeaderMap` already splits headers into two lists, for common (interned) and uncommon headers, it seems like it could have a third list specifically for `Set-Cookie` values. The various methods of `HTTPHeaderMap` that take a header name would have to add a match for `Set-Cookie`, but since `Set-Cookie` is a common header (and assuming it stays that way), the match is a simple enum comparison.

Some questions that are not yet clear to me at this point are how this change would affect any other consumers of `HTTPHeaderMap` in WebCore. In particular, there is at least one consumer (`WebSocketHandshake::serverSetCookie`) which uses `HTTPHeaderMap` to get the `Set-Cookie` value, which currently returns a combined string that isn't perfectly recoverable. Is other code that depends on `Set-Cookie` headers getting the header values from some other API?

[youenn fablet]

We should probably not change HTTPHeaderMap. We can change the FetchHeaders class directly.
WebSocketHandshake is deprecated code, it is probably not worth fixing.

[Andreu Botella]

For Set-Cookie, combining multiple values with comma followed by whitespace is lossy, since you can have valid values such as "foo=bar; Expires=Thu, 01 Jan 1970 00:00:00 GMT", or even "bar=baz; Path=/test/a, b=c" (where "/test/a, b=c" is the path). Therefore, you can't accurately split a pre-combined value. And this would be observable when constructing Headers instances.

Alternatively, since Set-Cookie is both a forbidden request and response header, `FetchHeaders` could keep track of the Set-Cookie values only if the guard is `FetchHeadersGuard::None`, while maybe storing the combined value in the underlying `HTTPHeaderMap`. This would work, but it seems fragile, since the `FetchHeaders` state would not directly correspond to the `HTTPHeaderMap`'s state.

[youenn fablet]

Why would we need to store the Set-Cookie combined value in HTTPHeaderMap?
AIUI, the goal here is to have a general FetchHeaders container, Set-Cookie headers would only be accessed by JS.

[Andreu Botella]

Pull request: https://github.com/WebKit/WebKit/pull/9490

[Radar WebKit Bug Importer]

<rdar://problem/104946593>

[Karl Dubost]

Current Status on
https://wpt.fyi/results/fetch/api/headers/header-setcookie.any.html

[EWS]

Committed 260533@main (77fd8deab6cb): <https://commits.webkit.org/260533@main>

Reviewed commits have been landed. Closing PR #9490 and removing active labels.