Looking at the shipping entry in chromestatus, it seems to lack the
necessary reviews for privacy, security and so on. Can you please
request those parts?
(Yoav mentioned this last week but maybe his mail got lost)
/Daniel
On 2026-09-28 16:39, Frédéric Wang Nélar wrote:
Le 21/09/2026 à 20:17, 'Dan Clark' via blink-dev a écrit :
*/> Specification/*
/> https://github.com/whatwg/html/pull/11620/
Is anything blocking this spec PR from landing?
Patrick can say more but I think this just pending review from the
WHATWG editors and addressing review comments, no fundamental blockers.
That said, this PR is much bigger that the small changes proposed
here. Actually none of the compression dictionary PRs
(https://github.com/whatwg/html/pull/11620
https://github.com/w3c/webappsec-clear-site-data/pull/94
https://github.com/whatwg/fetch/pull/1854) are merged yet but API
owners already approved shipping this feature in
https://groups.google.com/a/chromium.org/g/blink-dev/c/MuaRf28nExk.
The change I'm proposing here only aligns with the spec PR / tests /
webkit so in some way, doing soe would help a bit to get the spec PR
merged.
> *Interoperability and Compatibility*
/No information provided/
/
/
Since this would change a shipped API, can you comment on the
compatibility risk? Is there a possibility that sites already using
the feature could be affected?
Again, Patrick is probably in a better position to comment, but AFAIK
we haven't done any stats on current usage, because the expectation
that this change is minor and wouldn't have compat impact:
- For the fetch parameters, I understand they were too restrictive in
the initially shipped implementation, and were also ignoring
attributes that allow to change the default behavior. So removing this
restriction shouldn't "break" websites (in the sense that some fetches
could start being blocked). It also aligns with what other kinds of
links are doing, so it's something more expected for developers and
following existing security models.
- Regarding the "compression-dictionary" string, typical way of
triggering a dictionary load is via the link element / header and the
destination string is only set when the fetch request is created,
without implication on how the compression dictionary is used later.
It's possible for developers to observe this destination string (WPT
tests I mentioned above do that with some complex logic involving a
worker that observes fetch events) but it's not clear to me what would
be the use case for that.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9b21640-1e86-4e13-95d6-495ec8b8d2c8%40gmail.com.
