tl;dr: Chrome will start blocking 'Set-Cookie' request headers on outbound fetch requests.
Long version: The getAll() interface for Headers requires special complex handling of the Set-Cookie header, as it cannot just be combined, since it is semantically a response header. By forbidding 'Set-Cookie' as a request header, we avoid leaking this complexity into requests, as it is not useful for requests anyway. (spec discussion <https://github.com/whatwg/fetch/issues/973>) There was a UseCounter (results <https://chromestatus.com/metrics/feature/timeline/popularity/4152>) that was added to verify the usage of 'Set-Cookie' header on outbound fetch requests in Chromium. It was concluded that the % of pages that set a "set-cookie" header on an outbound fetch request hovers around 0.0003%. Further testing indicated that the two most popular domains that set the 'Set-Cookie' header on outbound fetch requests, still continue to work fine when all outbound 'Set-Cookie' headers were removed (i.e. return 200 status codes, identical data, identical response headers). As such, it was concluded that we could safely make this change. This is technically a web-facing change, though a small change to bring the Chrome implementation in line with the Fetch spec (spec PR <https://github.com/whatwg/fetch/pull/1453>). The impact seems small (as indicated by the UseCounter), and only positive by reducing complexity. Regards, Nidhi -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAMybV%3DZgJ00UufGZEDb_m5KGoCJ26uk_dJPYOKmQD4GDg%40mail.gmail.com.
