Accept 'sec-'-prefixed headers as CORS-safelisted.

[mikewest]

As discussed in #993.

@yoavweiss: Is there a better bug that we should link this to? I know you've had a lot of conversations on this topic.

@annevk: I'm not entirely sure how best to phrase this. I was hoping for some mechanics in infra... is "begins with the string XXX" good enough, or should I be more explicit?

Thanks!

---

Preview | Diff

[yoavweiss]

So I don't have an open issue for this, but I do have an open PR. This replaces it, and is nicer (with a lovely note), so I can obsolete the other one.

[yoavweiss]

LGTM

[annevk]

The other thing we should point out here is #880 (comment). In particular, if Fetch isn't in control of setting these headers, you might be in for a surprise with service workers.

[mikewest]

I don't quite follow where that conversation ended up. What's the behavior in Service Workers that we want? What behavior would surprise developers? @yoavweiss

[yoavweiss]

So, the surprising bits would be that Sec- prefixed headers would disappear from the requests when developers would modify the request in SW in any way (but won't disappear for pass-through cases).

For the CH case, I think we could solve this by re-adding them below SWs (but @annevk had reservations). For Fetch-Metadata, maybe you could simply add them below SWs?

[annevk]

I think for Fetch-Metadata all is in order because they are set as part of main fetch.

[annevk]

I tried to write a patch to address my comment, but while doing so I discovered another problem. Namely, https://fetch.spec.whatwg.org/#cors-unsafe-request-header-names. And it's really two problems:

1. With enough Sec- headers the 1024 limit would get breached.
2. As currently written we'd ask the server to safelist Sec- headers, which doesn't make a lot of sense.

I suspect we don't want to change https://fetch.spec.whatwg.org/#cors-safelisted-request-header after all, but only want to change https://fetch.spec.whatwg.org/#cors-unsafe-request-header-names which is what ends up being used. However, we need to think through the value limit problem a bit.

[toyoshim]

Hi Anne,

Sec- is also listed in https://fetch.spec.whatwg.org/#forbidden-header-name.
So, I think it's completely safe to skip them in the 1024 limit counting. We can ensure that these are not set or modified by users' JavaScripts.

[annevk]

Up to a point, part of the reason for the limit is to avoid hitting server limits. If user agents add a lot of Sec- headers, or they get attacker-controlled values, we're back to square one. So I don't think it's that easy unfortunately.

[toyoshim]

Ah..., I see.
Thank you for your clarification.

Since we will have more Sec- prefixed headers day by day, it's likely to increase chance to send the preflight for almost all cross-origin requests.

I just started investigating performance implication caused by the preflight, and this point may contribute to revisit the origin policy supporting for the orogin-wide preflight-like query.

[annevk]

Closing this per the above comments and as it's no longer blocking #993. I filed #1186 as follow-up.