[whatwg/fetch] CORS: arbitrary blocking of accept header based on length (#862)

When the accept header is larger than 1024 bytes, the request gets blocked. This length looks quite arbitrary: is there a reason for this?

The length breaks use cases where a browser script is used to query different web resources on the fly.

Asking all open web resource servers to set the `Access-Control-Allow-Headers: accept` in order to circumvent this seems like much to ask for no real added security?

### Reproducing in Chromium

```javascript
// Test 1: works
fetch('https://graph.irail.be/sncb/connections?departureTime=2019-01-27', {headers: new Headers({accept: "application/ld+json"})}).then(async (response)=> { console.log(await response.json())});
```

```
// Test 2: fails
fetch('https://graph.irail.be/sncb/connections?departureTime=2019-01-27', {headers: new Headers({accept: "application/trig;q=1.0,application/n-quads;q=0.7,text/turtle;q=0.6,application/n-triples;q=0.3,application/ld+json;q=0.3,text/n3;q=0.2"})}).then(async (response)=> { console.log(await response.json())});
```

### In other browsers

Mozilla docs have this to say:
> Note that certain headers are always allowed: Accept, Accept-Language, Content-Language, 
> Content-Type (but only with a MIME type of its parsed value (ignoring parameters) of either 
> application/x-www-form-urlencoded, multipart/form-data, or text/plain). These are called the simple 
> headers, and you don't need to specify them explicitly.

Src: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers#Directives

The test cases do work in Firefox.

### Context

We are working on querying open web resources. Setting a long Accept header is therefore quite normal: we can parse a lot of different formats.

Related issue: https://github.com/comunica/comunica/issues/373

-- 
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/862

Received on Monday, 28 January 2019 11:15:29 UTC