Skip to content

v1.6.5 — the Chrome identity now sends PRIORITY, because Chromium does

Choose a tag to compare

View all tags
@latentharbor latentharbor released this 02 Aug 02:25
· 22 commits to main since this release
v1.6.5
ef3032a

Chromium sets the PRIORITY flag on its request HEADERS — flags 0x25, carrying 80 00 00 00 ff:
exclusive, dependency 0, weight byte 255. This package never set it, so profiles.chrome produced a
frame layout that differed from Chromium's even where every value above it matched. 1.6.2 found
it with the h2 capture and wrote it down; 1.6.5 emits it.

If you use tunnelfetch/profile/chrome over HTTP/2, your request HEADERS frame changes in this
release. That is the fix. profiles.curl is unaffected — curl sends no priority, and the default
stays "do not send".

RFC 9113 §5.3.2 deprecates the mechanism and this package still ignores every PRIORITY frame it
receives. Sending it is a statement about identity, not a request to be prioritised.

The values are read out of the committed capture, not chosen.

The test is the point

Three bugs in this area have had one shape:

  • http2ConnectionWindow — declared in a profile, never read; Chrome sent curl's window
  • the SETTINGS flight — curl 8.21.0's ClientHello above curl 8.7.1's values
  • the flow-control window — advertised 64 KiB, accounted 10 MiB; every large body hung

Every one would have been caught by a test that folds the profile the way the Client folds it and
then reads the bytes off the wire. That is what this release adds, for both profiles, and it was
checked against both failure shapes: removing the profile's declaration fails it, and removing the
key from applyProfile's copy list — the http2ConnectionWindow bug replayed exactly — fails it
too.

Verified against a real origin as well, because the last frame-level change shipped a hang: the
Chrome identity fetched 9,141,067 bytes over h2 from a CDN, status 200.

1244 offline tests pass.

Assets 2
Loading