PSA: Adding 'Set-Cookie' header to Fetch's forbidden header names

317 views
Skip to first unread message

Nidhi Jaju

unread,
Jun 22, 2022, 12:30:48 AM6/22/22
to blink-dev, Yutaka Hirano

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)


There was a UseCounter (results) 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). The impact seems small (as indicated by the UseCounter), and only positive by reducing complexity.


Regards,

Nidhi

Yoav Weiss

unread,
Jun 22, 2022, 1:47:20 AM6/22/22
to Nidhi Jaju, blink-dev, Yutaka Hirano
That sounds like a small enough spec alignment to not require a full fledged intent. Thanks for the PSA!

--
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+...@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.
Reply all
Reply to author
Forward
0 new messages