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
On 2/15/23 15:48, Yoav Weiss wrote:
So this is something that the backend community is interested in, but
that is of no real interest to the front-end community?
--
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/107faa90-026d-0f67-8523-a3fa36ee3700%40igalia.com.
