1905759 - ResourceTiming and NavigationTiming nextHopProtocol should be empty for cached resources

Status: UNCONFIRMED

(Core :: DOM: Performance APIs, defect, P2)

Description

[Nic Jansma]

Steps to reproduce:

1. Navigate to https://dev.nicj.net/nexthopprotocol-transfersize.html
2. This repro page reports the nextHopProtocol and transferSize of the page (NavigationTiming) and a simple Fetch (ResourceTiming)
3. On the initial page load, you should see h2 and some amount of bytes transferred
4. If you click on "navigate to same page on domain 1" it'll re-navigate to the same page, which should be in the HTTP cache
5. The nextHopProtocol is still listed as h2 even though transferSize=0 (it's loaded from the disk or memory cache)

Actual results:

The nextHopProtocol is still listed as h2 even though transferSize=0 (it's loaded from the disk or memory cache)

Expected results:

ResourceTiming specifies that content fetched from application caches should have nextHopProtocol be empty:

https://w3c.github.io/resource-timing/#sec-performanceresourcetiming

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:fdoty, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Dave Hunt [:davehunt] [he/him] ⌚BST]

@Nic I'm unable to open https://dev.nicj.net/nexthopprotocol-transfersize.html. Can you confirm if this is still an issue? Also, do you know if there's a web platform test for this? A quick look shows that it could be covered here.

Comment 3

[Nic Jansma]

@Dave apologies, I've fixed the repro URL: https://dev.nicj.net/nexthopprotocol-transfersize.html

Firefox 142.0.1 shows the same behavior as reported above, where nextHopProtocol is 'h2' or 'h3' instead of '' upon cache hit. Chrome v139 does as well FWIW.

https://github.com/web-platform-tests/wpt/blob/master/resource-timing/sizes-cache.any.js looks like it's doing a similar scenario, though it's not checking nextHopProtocol as far as I can tell.

Comment 4

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Thanks Nic! I had a look through the Resource Timing spec and I only see nextHopProtocol being empty for cross-origin resources without TAO. I couldn’t find anything that says it should be empty when the resource comes from application caches. Maybe I’m missing something, or maybe the spec has evolved since this was reported?

Comment 5

[Nic Jansma]

I've been trying to interpret the specs a bit as well: between Resource Timing and Fetch, I think it would suggest the nextHopProtocol should be blank in case no actual connection is established.

Starting with this text:

The nextHopProtocol getter steps are to isomorphic decode this's timing info's final connection timing info's ALPN negotiated protocol. See Recording connection timing info for more info.

That links out to these sections of Fetch:

• https://fetch.spec.whatwg.org/#fetch-timing-info-final-connection-timing-info
• https://fetch.spec.whatwg.org/#record-connection-timing-info

It's a bit hard to follow everything, but it feels like if no new connection was established then either the "timing info" should be null, or, its' nextHopProtocol should be null.

The ResourceTiming spec itself has a callout for the transferSize getter steps which sets transferSize to 0 for local cache. Maybe we should be doing something similar for nextHopProtocol? I'll open an issue to discuss.

Comment 6

[Nic Jansma]

FWIW I think we had spec language specifying nextHopProtocol should be empty string prior to our alignment with Fetch; see

https://github.com/w3c/resource-timing/issues/73
https://github.com/w3c/resource-timing/pull/78

New issue opened:

https://github.com/w3c/resource-timing/issues/419