Drop Origin & Accept from Access-Control-Allow-Headers value

[sideshowbarker]

This change drops the Origin and Accept header names from the value of the Access-Control-Allow-Headers response header sent by Synapse. Per the CORS protocol, it’s not necessary or useful to include those header names.

---

Details:

Per-spec at https://fetch.spec.whatwg.org/#forbidden-header-name, Origin is a “forbidden header name” set by the browser and that frontend JavaScript code is never allowed to set.

So the value of Access-Control-Allow-Headers isn’t relevant to Origin or in general to other headers set by the browser itself — the browser never ever consults the Access-Control-Allow-Headers value to confirm that it’s OK for the request to include an Origin header.

And per-spec at https://fetch.spec.whatwg.org/#cors-safelisted-request-header, Accept is a “CORS-safelisted request-header”, which means that browsers allow requests to contain the Accept header regardless of whether the Access-Control-Allow-Headers value contains "Accept".＊

So it’s unnecessary for the Access-Control-Allow-Headers to explicitly include Accept. Browsers will not perform a CORS preflight for requests containing an Accept request header.

Related: matrix-org/matrix-spec-proposals#3225

Signed-off-by: Michael[tm] Smith [email protected]

---

＊ There is actually one edge case in which browsers won’t allow an Accept header in a request: If the value contains a “CORS-unsafe request-header byte” https://fetch.spec.whatwg.org/#cors-unsafe-request-header-byte. But in that case, the Accept header is anyway malformed and is therefore not going to have its intended effect. So that edge case doesn’t merit including Accept in the Access-Control-Allow-Headers value.

[richvdh]

@turt2live has volunteered to check this as someone more familiar with web dev and CORS.

[turt2live]

this seems fine from a web dev perspective

[richvdh]

thanks everyone!