What is the issue with the Fetch Standard?
The network partition key step says secondKey can "be null or an implementation-defined value".
This seems like a historical accommodation, with all major engines partitioning fetch() more strictly today.
But for new technology, this seems to leave the door ajar for no reason.
For WebTransport, whose constructor builds a fetch request in "webtransport" mode, a null secondKey lets a compliant UA pool QUIC sessions across cross-origin iframes on the same top-level page. Seems problematic.
No engine ships WT pooling yet, so tightening is free.
Possible avenues:
- A: prescribe a non-null
secondKey for everyone (e.g the request's client's origin or its site)
- B: when request's mode is
"webtransport", prescribe A
- C: when request's mode is
"webtransport" and secondKey doesn't satisfy A, set new to "yes-and-dedicated"
What is the issue with the Fetch Standard?
The network partition key step says
secondKeycan "be null or an implementation-defined value".This seems like a historical accommodation, with all major engines partitioning
fetch()more strictly today.But for new technology, this seems to leave the door ajar for no reason.
For WebTransport, whose constructor builds a fetch request in
"webtransport"mode, anullsecondKey lets a compliant UA pool QUIC sessions across cross-origin iframes on the same top-level page. Seems problematic.No engine ships WT pooling yet, so tightening is free.
Possible avenues:
secondKeyfor everyone (e.g the request's client's origin or its site)"webtransport", prescribe A"webtransport"and secondKey doesn't satisfy A, set new to"yes-and-dedicated"