[COOP] Header syntax

[jugglinmike]

The COOP proposal clearly defines the Cross-Origin-Opener-Policy HTTP response header as a non-structured-header with exactly three valid values. However, @domenic has recently observed:

I just kind of thought we were not creating any new non-structured headers. (And, it'd be pretty weird if COOP was one thing and COEP another.)

I can't speak to the first observation, but parity with COEP does seem valuable. Since the parsing rules for COEP are currently in flux, I wanted to see if a similar change should be considered for COOP.

[zcorpan]

@annevk @mikewest @mnot

[annevk]

Both should be forward-compatible with Structured Headers. I'm not sure we want to fully depend on that until it's ready.

[zcorpan]

So that suggests treating parameters as "fail parsing", for now.

[domenic]

What?? That suggests the opposite to me. Why would you want browsers that implement the non-SH spec to be unable to parse the SH version?

[annevk]

That is how other equivalent headers work today that we might upgrade to SH once it's ready. Making them SH-compatible now while that might still change seems unwise.

[annevk]

To restate, my preferred way of doing this for both COOP and COEP is to start with a byte-case-sensitive comparison of the value with the allowed strings and migrate to SH once that is an RFC as that's effectively the point IETF commits to not make incompatible changes. It seems highly unlikely a byte-case-sensitive comparison of these values will be incompatible with a future likely more permissive SH syntax.

[domenic]

It seems highly unlikely a byte-case-sensitive comparison of these values will be incompatible with a future likely more permissive SH syntax.

It would be incompatible. Consider the following sequence of events:

1. We spec a byte-case-sensitive comparison of values.
2. All browsers ship it. (Including browsers on 6-12 month update cycles.)
3. We switch to structured headers because we need a parameter, say same-origin;someparam=somevalue. This could either be done in standards space, or it could be done as a browser working to experiment while incubating a standard.
4. A server want to make use of this new functionality, and starts sending Cross-Origin-Opener-Policy: same-origin;someparam=somevalue.
5. Now, all browsers that don't implement the structured header version fail to get COOP set for that site.

This means that, in general, either sites will start cutting out browsers that don't implement new features (e.g., you can only play this SAB-using game in Browser X), or sites will be unable to deploy any updates to COOP until the long tail of byte-case-sensitive browsers fall off of their usage numbers.

[annevk]

I think incompatibility along those lines is acceptable as I expect we'll update to SH long before we'll make significant changes to these features. And also, I think it would be worse to be stuck with something that's almost SH, but not quite because SH changed.

[mnot]

What's the timeline for shipping this? SH is Almost Done™️.

[annevk]

Some of it has already shipped (Cross-Origin-Resource-Policy), some will likely ship in the order of months. Anyway, going from a simple literal comparison to SH seems like it should be straightforward once SH is done, either via shipping an update or from the start if SH arrives early.

[domenic]

We may want to use our structured header parser in Chromium for these headers (certainly for Origin Policy) from the beginning, although I guess with the direction things are currently going that means we would intentionally fail some web platform tests.

Perhaps it would be good to get WebKit's opinion as a tie-breaker for what the standard/tests should say.

[zcorpan]

The timeline for wanting to extend any of these headers with new parameters is, as far as I know, unknown or "maybe in a few years". Correct?

[annevk]

We haven't quite settled on how to do reporting. I think the simplest would be a distinct header, but if we end up flipping on that it would be within a shorter period. But again, I don't think we can start using parameter syntax until SH is FullyRFC Done™️.

[zcorpan]

Ah right, I forgot about the reporting use case.

I agree with @annevk, but I don't have a strong opinion on this. In particular, if @mnot thinks it's OK for browsers to ship with SH parsers and specs to start using them, then I think it's fine to do so. Until then, it seems better to let SH bake so it can make syntax changes without having to consider possible compat issues from early adopters.

[empijei]

Bumping this due to a recent discussion we had on how to add reporting to COOP.

It looks like there is some agreement that COOP should be a structured header to support report-to information.

WDYT about changing the spec accordingly? Can we move forward on this?

If not, would it make sense to at least implement it in a SH compatible way?

[annevk]

It should probably be tackled in #5334 at this point. I agree that we should do it. It'd be fine if dedicated parser tests land ahead of the change.

[mnot]

FWIW - SF (nee SH) is now in the RFC Editor queue.

[domenic]

I guess we should update all our cross references to "F" instead of "H"...