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

瀏覽次數:363 次
跳到第一則未讀訊息

Nidhi Jaju

未讀,
2022年6月22日 凌晨4:30:482022/6/22
收件者: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

未讀,
2022年6月22日 清晨5:47:202022/6/22
收件者: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.
回覆所有人
回覆作者
轉寄
0 則新訊息