Fetch: specify default accept header on cors preflight

[wanderview]

In https://crbug.com/995740 we have encountered a server that fails if the cors preflight options request does not have an accept header. It seems, though, the spec does not include accept on those requests.

The default accept / header is added in "perform a fetch" here:

https://fetch.spec.whatwg.org/#fetching

But cors preflight taps straight into "HTTP-network-or-cache fetch" further down the algorithm.

Is this intentional or an oversight in the spec?

[annevk]

Pretty sure it wasn't considered, though hard to say over a decade plus. Is the suggestion to always send Accept: */*?

[wanderview]

Yea, I was wondering if it should get the default of Accept: */*.

[annevk]

I think that's a reasonable change FWIW.

[wanderview]

This came up for chromium because we changed our CORS implementation recently. It seems prior to M76 we sent an accept header, but starting in M76 stopped sending the accept header.

[wanderview]

Firefox Nightly seems to send Accept: */* on the cors preflight.

[wanderview]

Its hard to quickly check safari since it doesn't seem to expose preflights to devtools network panel.

[toyoshim]

Confirmed that Safari also sends Accept: */* for the CORS preflight.
I will restore the original behavior to have the Accept in Chrome's new CORS.

[wanderview]

Updated the title to reflect that the spec should be updated to match browser implementations.

[mnot]

So, browsers are going to send an extra header on every preflight, just because one server was erroneously counting on it?

That seems like a path to bad things happening. Accept is completely optional in requests, and HTTP requires servers to be able to deal without it.

[toyoshim]

No. Sending the accept header was the original behavior of all UAs including chromium.

We'd just want to confirm the spec description if it reflects the actual UAs' implementation so that we can ship a brand new CORS implementaton as much compatible as possible.

Even if this is an optional one, we'd have an explit explanation to say so in the spec. Otherwise, we will receive bug reports from users continuously.

[domenic]

So, browsers are going to send an extra header on every preflight, just because one server was erroneously counting on it?

It's more like, browsers have always sent the header on every preflight, but until one of them accidentally removed it, we didn't realize that the spec was not aligned with implementations in this regard. Now that we realize that, we're fixing the spec.

[annevk]

Not sending Accept in various places has been tried a couple times if I remember correctly and always ended up failing. I suspect that unfortunately servers use it as a high-level filter for clients.