Intent to Ship: Fetch: Headers.getSetCookie()
Andreu Botella
Contact emails
abot...@igalia.com, ri...@chromium.orgExplainer
NoneSpecification
https://fetch.spec.whatwg.org/#dom-headers-getsetcookieDesign 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>FetchAPISearch tags
fetch, headers, cookie, Set-CookieTAG review
TAG review status
Not applicable, since the specification has already been changed to include this featureRisks
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)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name
Requires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1409512Estimated 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/ALink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5184534394437632
Philip Jägenstedt
--
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/63b8727a-9f01-e69d-f9b9-c46c2e1a8cbb%40igalia.com.
Yoav Weiss
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
Search tags
fetch, headers, cookie, 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?
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.
--
slightlyoff via Chromestatus
Rick Byers
LGTM2
--
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/00000000000083293c05f54c6612%40google.com.
Andreu Botella
Sorry for taking so long to reply.
One possible client-side use case enabled by this addition is as
part of a JS API for a proxy, possibly one that allows access to
public servers that aren't CORS-accessible:
// example.com doesn't support CORS!
const {headers, body} = proxyFetch("https://example.com");
console.log(headers.getSetCookie());
Such an API would allow access to any Set-Cookie
headers sent by example.com, by encoding them somehow in
non-filtered headers or in the response body. Such a returned Headers object wouldn't come directly
from fetch, but it would still be a
representation of HTTP headers.
But you're right that this API would be most useful for
server-side runtimes that don't do CORS or filter Set-Cookie headers because they have a
different security model than the web.
Andreu
Yoav Weiss
Sorry for taking so long to reply.
One possible client-side use case enabled by this addition is as part of a JS API for a proxy, possibly one that allows access to public servers that aren't CORS-accessible:
// example.com doesn't support CORS!
const {headers, body} = proxyFetch("https://example.com");
console.log(headers.getSetCookie());
Such an API would allow access to any Set-Cookie headers sent by example.com, by encoding them somehow in non-filtered headers or in the response body. Such a returned Headers object wouldn't come directly from fetch, but it would still be a representation of HTTP headers.
Andreu Botella
Yes, I was thinking of proxyFetch
as an API that wraps over a call to a proxy, such that you could
pass and get Headers objects that
correspond directly to the "raw" headers of the proxied request
and response. The proxyFetch
function would then encode and decode those "raw" headers somehow
in the actual connection with the proxy server, so they aren't
filtered out.