LGTM1 On Fri, Feb 10, 2023 at 7:05 PM Andreu Botella <abote...@igalia.com> wrote:
> Contact emails abote...@igalia.com, ri...@chromium.org > > Explainer None > > Specification https://fetch.spec.whatwg.org/#dom-headers-getsetcookie > > Design docs > https://github.com/whatwg/fetch/issues/973#issuecomment-902578584 > https://github.com/whatwg/fetch/issues/973#issuecomment-954815921 > > Summary > > Adds a way to get the values of multiple Set-Cookie headers without > combining them. In HTTP, Set-Cookie is a special header for historical > reasons because it can appear multiple times in a response but cannot be > combined, unlike other headers. Headers objects don't currently support > having multiple values of the Set-Cookie header, and this feature adds that > capability. > > > Blink component Blink>Network>FetchAPI > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EFetchAPI> > > Search tags fetch <https://chromestatus.com/features#tags:fetch>, headers > <https://chromestatus.com/features#tags:headers>, cookie > <https://chromestatus.com/features#tags:cookie>, Set-Cookie > <https://chromestatus.com/features#tags:Set-Cookie> > > TAG review > > TAG review status Not applicable, since the specification has already > been changed to include this feature > > Risks > > > Interoperability and Compatibility > > The interoperability risks are low, since this feature is currently being > implemented in all browser engines. This feature introduces one change to > the existing iteration behavior of Headers instances, in that they may now > yield multiple entries for Set-Cookie headers, when previously all > Set-Cookie headers were combined in a single iteration entry. Given that > this is only observable with user-created Headers objects, rather than with > ones associated with Request and Response objects, this risk can be > considered negligible. > > > *Gecko*: In development (https://phabricator.services.mozilla.com/D167897) > > > *WebKit*: In development (https://github.com/WebKit/WebKit/pull/9490) > > *Web developers*: No signals > > *Other signals*: Server-side JavaScript runtimes have been pushing this > proposal as part of the Web-interoperable Runtime Community Group > (WinterCG), since it allows them to use fetch-compatible HTTP server APIs. > In particular, Deno was involved in writing the spec change ( > https://github.com/whatwg/fetch/issues/973), and both Cloudflare Workers ( > https://github.com/whatwg/fetch/pull/1346#pullrequestreview-797738368) > and Node.js ( > https://github.com/whatwg/fetch/pull/1346#issuecomment-1171502837) were > supportive. > > Security > > Set-Cookie headers are forbidden request and response headers ( > https://fetch.spec.whatwg.org/#forbidden-request-header, > https://fetch.spec.whatwg.org/#forbidden-response-header-name), meaning > that Set-Cookie headers are filtered off of Request and Response objects. > This feature does not change that, and therefore does not introduce any > possible information leaks. > > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > N/A > > > Debuggability > > No DevTools support required, since this feature does not change the > behavior of Set-Cookie headers in network requests/responses, or otherwise > affect any aspect of the network stack. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? Yes > > Flag name > > Requires code in //chrome? False > > Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1409512 > > Estimated milestones > > No milestones specified > > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > N/A > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5184534394437632 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > 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/63b8727a-9f01-e69d-f9b9-c46c2e1a8cbb%40igalia.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/63b8727a-9f01-e69d-f9b9-c46c2e1a8cbb%40igalia.com?utm_medium=email&utm_source=footer> > . > -- 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/CAARdPYe9ZHK-FofZWb12ZTNfv-8MWo0LWgD7vkGVsuCnjv4EeA%40mail.gmail.com.
