On Thu, Feb 23, 2023 at 10:14 AM Andreu Botella <abote...@igalia.com> wrote:
> 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";
> <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.
>
What's `proxyFetch` in that example? Is that a fetch() from a server-side
proxy that's considered same-origin from the browser's perspective?
>
> 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/CAL5BFfVEruaDYxpxLai0-psWKAMC7mhPpgfpue7C1J-MX%3DStrg%40mail.gmail.com.
