fenced-frame
fenced-frame copied to clipboard
Add definitions for event reporting opt in headers
This issue was brought up in https://github.com/WICG/fenced-frame/issues/158.
This PR adds official definitions for the Allow-Fenced-Frame-Automatic-Beacons
and the Allow-Cross-Origin-Event-Reporting
response headers that are used for cross-origin opt in for their respective features.
I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?
I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?
The implementation of this expects string literals (true/false) rather than boolean values (?0/?1). I wasn't aware of the precedent set in RFC8941 at the time, and I had copied the syntax of an existing flag that was also not using the boolean convention when I had implemented this feature. Since the code is already in place, and since changing this to a boolean would delay getting this feature out by at least a month, I think it's better to keep the implementation as is and make sure the spec matches the implementation.
would delay getting this feature out by at least a month
As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?
As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?
Update: The team is proceeding with the change to boolean: https://chromium-review.googlesource.com/c/chromium/src/+/5542760