Re: [whatwg/fetch] RFC: a mechanism to bypass CORS preflight (#210)

Hey @bifurcation / @rlbmoz / whoever you are today:

> It's not clear to me why you want to go the .well-known route vs. having the original resource express the location of the policy:

> Access-Control-Policy: https://example.com/cors-policy

A couple of things.

1. This header is going to need to be on every response, so it's going to create a lot of bloat on the wire (and no, we can't rely on H2 header compression to save the day).

2. I really want to be able to Server Push the policy to the client.

I suppose something like this would work equally well:

    Access-Control-Policy: /

i.e., support (or even require) a relative URL. Even better:

    ACP: /

The assumption behind a `.well-known` resource is that it'd be site-wide. If we allowed different resources on a site to specify different `ACP`s, path granularity in the policy format wouldn't be necessary. Indeed, I'm wondering if it's necessary even when the policy _is_ site-wide.

> I am also worried about the consistency issue. If we do this, we should be explicit that the site policy overrides anything sent by the specific resource. Note that it is safe for the resource to send only the policy (and not the other CORS headers), since older browsers will fail closed.

+1. It might be interesting to think about a request header indicating that the client is using the site policy, so that the server can omit them -- but we'd have to be careful about things like caching.

> If we're going to have the origin set policy for sub-resources, it would be good to do it for more than just CORS. E.g., it would be nice to use this to set the upgrade-insecure-requests CSP directive for a whole site.

I've been asking for optional browser policy for years, so **yes please**. Happy to sketch up a more general mechanism if there's interest.

> I would like this a bit better if we could have the policy be signed by the origin. You could re-use normal web certificates for this, and it would have a few advantages: 
> 1. Better assurance in the HTTP case 
> 2. You would have to have a certificate (if not HTTPS) to get this optimisation
> 3. Policies can be distributed independently of the transport, so you could do things like having a single policy document have policies for multiple origins.

You're going to make me use JOSE, aren't you?

I'd be OK with this if it were optional at least in the common case (e.g., delivered over HTTPS).

> Net of all that, though, doing a foreign fetch service worker does seem simpler to me than revising the whole policy framework. Where are we on that idea? As an intermediate idea, you could imagine adding a service worker method to set this policy, so that you wouldn't have to do all the header munging.

I'd be happy prototyping something in a FFSW to gather data and prove a design, if it's ready. Is it?

I'm less happy if the endgame is that everyone who is unhappy with CORS is told to use FFSW.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/210#issuecomment-212193386