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.
On 2/23/23 10:23, Yoav Weiss wrote:
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 <http://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 <http://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/d1588284-6671-1814-6e1d-7ce34da3e4a1%40igalia.com.
