[whatwg/fetch] Would it be sound for CORS middleware to fail the CORS check if the request's method hasn't been explicitly allowed? (Issue #1517)

As I'm working on a principled (one may hope!) CORS middleware for Go, I have been driven to study the CORS protocol with more attention than I had formerly given to it. One of implementation dilemmas relates to requests whose method is one of the so-called [CORS-safelisted methods](https://fetch.spec.whatwg.org/#cors-safelisted-method): `GET`, `POST`, and `HEAD`.

Imagine an endpoint `/whatever` that supports all three methods, but for which I'd like the [CORS check](https://fetch.spec.whatwg.org/#concept-cors-check) to succeed as indicated by the table below:

|  mode \ method | `GET` | `POST` | `HEAD`|
| ------------------- | ------- | ------- | -------- |
| `no-cors`                 | ✅        | ✅           | ✅         |          
| `cors` (simple)        | ✅        | ❌           | ❌         |
| `cors` (preflighted) | ❌        | ❌           | ❌         |

The middle row is tricky: because requests using one of those three methods may not get preflighted, there's no opportunity to fail early, at the [CORS-preflight check](https://fetch.spec.whatwg.org/#cors-preflight-fetch-0), e.g. by responding with a status other than an [ok status](https://fetch.spec.whatwg.org/#ok-status).

I'm considering letting my middleware library fail the CORS check (by omitting the ACAO and possibly ACAC headers) if the request's method hasn't been explicitly configured by the client of my library as an allowed method. However, I'm wondering whether that's a sound approach...

Can you think of anything wrong with such an approach? Or can you think of a better alternative?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1517

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1517@github.com>