[html] Add tests for parsing COOP values

[jugglinmike]

No description provided.

[domenic]

I think we need to clarify whether the plan is for COOP to be a structured header or not, since that impacts various results...

[jugglinmike]

Has that change been discussed online?

[domenic]

Not to my knowledge; 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.)

[jugglinmike]

Got it. I filed whatwg/html#5172 to discuss this

[annevk]

As per whatwg/html#5172 (comment) I think this is the way to go, perhaps with a comment indicating we want to change this once SH is an RFC.

[zcorpan]

I've now updated this to match the current specs.

• HTML now says COOP is a Structured Header and doesn't disallow parameters.
• Structured Field Values changed details around whitespace (see Inconsistent rules around whitespace httpwg/http-extensions#1251 ), byte sequence syntax, allows * in tokens.

[zcorpan]

I also removed the same-origin\0 test because it now resulted in a network error in chromium (intentional per #25181 (comment) ) for wptserve. (cc @ziransun @Hexcles , maybe related to python3 changes?)

A few tests time out for me in Chrome. Not sure why.

[zcorpan]

I had misunderstood the layering between HTTP and SFV. HTTP still trims OWS around the field-value: httpwg/http-extensions#1251 (comment)

Now fixed.

[annevk]

I have not done an extremely detailed take, but I'm assuming that the set of cases that now cause a policy to be enforced is strictly additive to what we had originally. If that's not the case let's revisit.

[zcorpan]

Thanks @annevk. Some tests here are still getting TIMEOUTs in both chrome and firefox. I tried to figure out what is causing it, without luck so far. For example, the "same-origin\t" test times out, while "same-origin " passes.

https://staging.wpt.fyi/results/html/cross-origin-opener-policy/header-parsing.https.html?label=pr_head&max-count=1&pr=20873

Am I missing something obvious?

[annevk]

It might be the Python header API not dealing with invalid values the way you would want for testing purposes. If that's the case you could write out the entire message instead in raw...

[jugglinmike]

The procedural test generation logic derives a name for the BroadcastChannel from the COOP value. Just like the COOP itself, the channel name is passed around via query string parameters, so we have to take care to URL-encode it as well.

The latest commit fixes the timeouts. Chromium passes all 24 subtests, and Firefox fails 2:

FAIL unspecified document opening popup to https://web-platform.test:8443 with COOP: "same-origin;same-origin" - assert_equals: name expected "" but got "unspecified_to_SAME_ORIGIN_same-origin;same-origin"
FAIL unspecified document opening popup to https://web-platform.test:8443 with COOP: "same-origin; foo=bar" - assert_equals: name expected "" but got "unspecified_to_SAME_ORIGIN_same-origin;-foo=bar"

[Hexcles]

I also removed the same-origin\0 test because it now resulted in a server error for wptserve. (cc @ziransun @Hexcles , maybe related to python3 changes?)

So that's a null byte at the end? Could you provide some more details (stacktrace maybe?)?

[zcorpan]

Thank you @jugglinmike!

The stability checks fail because they time out. I think since changing common.js causes all tests using it to run in the stability check (10 times each), and many of the tests take a long time to run, the whole thing takes too long time to run. So I think we'll need to admin-merge this (after review).

@Hexcles I can open a new PR to reintroduce the null byte test, to decouple from the rest here. Thanks!

[zcorpan]

@annevk you have reviewed this but there were 2 commits since.

[annevk]

Having seen the COEP comments I guess we should address here too what bytes are going to be emitted by the server. And what shortcomings this approach has (in that 0xFF isn't feasible). Perhaps we should change approach so we can effectively specify bytes?

[zcorpan]

Yeah, good point. I've changed it now for this PR to specify bytes.

[annevk]

Did you check that other users of common.js not rely on encodeURIComponent? Especially reporting tests might be impacted, perhaps?

[zcorpan]

Hmm yes, though it's not obvious from test results (chrome, firefox).

But instead of sprinkling encodeURIComponent everywhere, I'm thinking about doing it differently, like using an object for the 0xFF test case:

  [SAME_ORIGIN, { percentEscaped: "same%FForigin" }, true]

[annevk]

That seems reasonable, though I'd name it percentEncoded.

[zcorpan]

Done.

[zcorpan]

Thanks! I'll admin-merge, per #20873 (comment)