Raising to P1, release blocker for M70. Need a bisect to figure out when this broke. If M71 then this can be targeted at that version, but this absolutely must be fixed - it's breaking customer sites.

It is not "simple" any more. See "If value’s length is greater than 128, then return false." in https://fetch.spec.whatwg.org/#cors-safelisted-request-header. The spec change is https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b. We did that to mitigate a security issue.

Able to reproduce the issue on the reported chrome 71.0.3560.0 latest canary 71.0.3561.0 using Windows 10, Ubuntu 14.04 Mac 10.13.6. 

Bisect Info:
================
Good build: 71.0.3545.0
Bad build:  71.0.3546.0
You are probably looking for a change made after 589433 (known good), but no later than 589434 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/299669f962e6ab3d50f2e445f9878a1d07141263..3301bab535e31ab83871627aa38356586b452c5e

Suspect: https://chromium.googlesource.com/chromium/src/+/3301bab535e31ab83871627aa38356586b452c5e

Reviewed-on: https://chromium-review.googlesource.com/1212425

Yutaka Hirano:Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

Since there is a clear bisect, can we get a fix/ revert soon.

It's not clear that's desired, right? Fixing this would be a security regression of sorts.

It'd be interesting to learn from the reporter what length for Accept header values they need, so that we can perhaps adjust the limits.

Hi, original reporter here. Our accept header length can vary depending on the type of request, but I would never expect anything to be longer than 1024 bytes (and as long as it's a rare occurrence, some pre-flights would be an acceptable compromise and I can update our servers to support them when they do happen).  I admit our usage is non-standard and would be happy to have better alternatives, but we need to avoid pre-flighting every user request.

I still have a couple of questions:

1. Doesn't Chrome normally have a deprecation process for changes like this? Was that skipped because this is considered a security issue? Seems odd to make this change without any kind of previous deprecation timeline or warning in stable.

2. Does anyone have a link as to what exactly the security concern here is? I clicked through the changes and referenced issues but couldn't actually find out why this change occurred to begin with.

3. None of this would matter to us if there was a way for our domain/sub-domain to advertise that it is CORS enabled for ALL requests rather than sending a pre-flight for every single request. It's a map/3D tile server so every request has the same CORS settings.  I would love to be wrong here, but my understanding is that there is no way to do this. Is there any way to get a conversation started on perhaps adding this feature to the spec? I know it's outside the scope of this issue, but with any bug/feature I always like to discuss the root cause that got us into it to begin with.  If someone could point me in the right direction to discuss this, I'll start a conversation there.

> #11

1. Yes, I didn't advertise the change as it was a security issue. I also thought that 128 bytes was generous enough and few innocent web developers would be affected.

2. https://www.usenix.org/conference/usenixsecurity18/presentation/chen-jianjun

3. It's Origin Policy. The feature is being developed. See https://github.com/WICG/origin-policy.

Friendly ping to get an update as it is marked as stable blocker.
Thanks..!

matt.amato@, 
Please check C#12 comments & update the bug accordingly as it is marked as stable blocker.
Thanks..!

jmukthavaram, thanks for the bump, I thought I already replied.

yhirano, thanks for the links.

I'm really excited to hear about origin-policy, but it looks like it's still in the incubation stage and the spec hasn't been touched in a year.  What are the chances that it gets implemented anytime soon or moves further in the standards process?

The presentation you linked to indicates the 5 major servers support up to 8K headers, so a 128 byte limit seems overly small. As I stated in #11, I'd be fine with a 1K limit as it fits our needs most of the time and should make OPTIONS requests go from millions per-day to a few hundred. Obviously this would be a temporary measure until chrome supports the new origin-policy.

I understand our site it just one use case, but this change as-is would really hurt us until origin-policy is in place. Please let me know if there's anything else I can do to help.

As Anne says, we can change the threshold, for example to 256, if your use is legitimate. If you want that, please let us know how you use the Accept header. Otherwise, I will close this bug WONTFIX.

#16: Origin Policy is being actively developed: https://crbug.com/751996

The spec indeed hasn't been touched in a while. The idea is to get the feature running, and improve the spec with what we learned from that. That tends to make for better specs.
I'm aiming for a limited trial (origin trial) of OP in Q1/2019, but that would imply general availability (or even cross-browser availability) to be somewhat later than that. I find the 'real-world' timing of feature releases to be hard to predict.

#17: the submitter's already pointed out that their use case is the virtual globe https://cesiumjs.org/ , and that this change in Chrome has doubled the number of network requests their server receives. Is that enough to motivate increasing the limit on these headers from 128 bytes to 1K as they've requested?

A request to https://assets.cesium.com/1/1/1/0.terrain?extensions=octvertexnormals-watermask&v=1.1.0 has "Accept: application/vnd.quantized-mesh,application/octet-stream;q=0.9,*/*;q=0.01,*/*;access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJkZDk3NmQ4ZS03Njg5LTRmOTktODNhNS01MTUyODAzNDNhMGUiLCJpZCI6MjU5LCJhc3NldHMiOnsiMSI6eyJ0eXBlIjoiVEVSUkFJTiIsImV4dGVuc2lvbnMiOlt0cnVlLHRydWUsdHJ1ZV19fSwic3JjIjoiYjBkYzNkMWItODgzNi00MzAxLThiZjktZjQ5ZGNkNjYxODI3IiwiaWF0IjoxNTQwMTkzMTM4LCJleHAiOjE1NDAxOTY3Mzh9.KVUgcKG8WjlUDv_AVwR-voOqGyhK25kI0BCJbUuNUyI".

This is a total abuse of that header. I, personally, do not think this is a use case that should be supported.
Why is this not a cookie or something?

I feel 1KB is big enough even for attacker to embed magic sequences to compromise existing services by the header value.

Also agreed with #c21.

@vogelheim, thanks for the info. I know timelines are impossible to predict, but it's good to hear it's at least on the radar. Please let me know if there's anything me or my team can do to help, such as testing out early versions of the Chrome implementation or providing other feedback.

@phistuck and @toyoshim, I have been completely up front about our use case being atypical (I would not call it abuse since the header value is well formed). It is not doing anything illegal outside of the spec (or at least wasn't at the time it was written since the length requirement is a new addition). As I said previously, we currently serve ~10 million CORS requests per day and we expect that number to continue to increase in size. This new limitation on header length would literally double the number of requests to our server because of the sudden pre-flight requirement. The  origin-policy work seems to be the perfect solution, but is a long way away.

If anyone has any guidance that doesn't involve triggering pre-flight, I'm all ears. I also can't use a query parameter because that would bust the cache (the value changes across page refreshes).

#23 - I did ask -
> Why is this not a cookie or something?

M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.