Re: [slightlyoff/ServiceWorker] CORS pre-flight for foreign fetch (#880)

So what is being suggested is to change the options passed to `registerForeignFetch` to be something like this?
```idl
dictionary ForeignFetchOptions {
  // existing attributes:
  required sequence<USVString> scopes;
  required sequence<USVString> origin;

  // new attributes:
  sequence<USVString> methods = ["GET", "HEAD", "POST"];
  sequence<USVString> headers = [];
};```

Foreign fetch would then only intercept requests whose method is one of those specified in the options (I don't actually think webidl allows having a non-empty sequence as default value for an attribute though). Requests with other methods would just hit the network.

I'm not entirely sure how headers should behave though. I suppose by default foreign fetch could only intercept requests that only have headers which are CORS-safelisted request headers, and you can specify more headers in the options to intercept more requests.

(for what it's worth, in at least the initial chrome implementation I'm likely going to limit foreign fetch to entirely only intercept requests that would not result in a CORS preflight. So there wouldn't be any way for the service worker to opt-in to more methods and/or headers. This is primarily because doing anything else would require a major refactoring of the way CORS is implemented in chrome).

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/880#issuecomment-224355099