Define Resource Timing in terms of Fetch #39
Labels
Milestone
Comments
Closed
This was referenced Mar 3, 2016
|
See web-platform-tests/wpt#2919 for test. |
This was referenced Jun 1, 2016
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
May 18, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
May 19, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
May 19, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
May 19, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Commit-Position: refs/heads/master@{#770192}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
May 19, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Commit-Position: refs/heads/master@{#770192}
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this issue
May 19, 2020
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Commit-Position: refs/heads/master@{#770192}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
May 27, 2020
…ponse., a=testonly Automatic update from web-platform-tests Fetch: Track protocol information in Response. This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Commit-Position: refs/heads/master@{#770192} -- wpt-commits: ca0b9b08b4e1f770ffa7722b730a712da379722f wpt-pr: 23676
xeonchen
pushed a commit
to xeonchen/gecko
that referenced
this issue
May 27, 2020
…ponse., a=testonly Automatic update from web-platform-tests Fetch: Track protocol information in Response. This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Commit-Position: refs/heads/master@{#770192} -- wpt-commits: ca0b9b08b4e1f770ffa7722b730a712da379722f wpt-pr: 23676
|
I believe this can be closed. |
|
Amazing work!! |
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this issue
Oct 14, 2022
This CL plumbs three protocol related fields through the fetch API Response internal representation: 1) The |alpn_negotiated_protocol| which is set for TLS negotiated protocols like H2. 2) The |connection_info| enumeration which includes information on older protocols like H1. 3) The |was_fetched_via_spdy| boolean which is set for H2. The first two values, |alpn_negotiated_protocol| and |connection_info|, are collectively used to populate the `PerformanceResourceTiming.nextHopProtocol` value. They are also both used to populate the correct protocol information in the devtools network panel. The |was_fetched_via_spdy| boolean is used to populate the deprecated `navigator.chrome.loadTimes().wasFetchedViaSpdy` property. Without this plumbing the resulting exposed values will generally be wrong if the page loaded via a service worker with a FetchEvent handler. For example, `PerformanceResourceTiming.nextHopeProtocol` is always the empty string for resources loaded via a service worker that does a pass-through or cached load. This CL also plumbs these values through the cache_storage layer. While that may seem unintuitive at first, since the data is coming from disk, it matches the behavior when loading from http cache. Generally the values represent the protocol used to originally load the response and are persisted in the cache. I believe this also matches the cache_storage spec where Response objects are effectively held in an array without any serialization or deserialization where data would be lost: https://w3c.github.io/ServiceWorker/#cache-objects Although the spec is not currently clear if the protocol information lives on the response object, its not clear where else it could be stored. This should become clearer once the Resource Timing spec is integrated with the fetch spec in: w3c/resource-timing#39 This CL includes an automated WPT test for the `PerformanceResourceTiming.nextHopProtocol` value since we can verify that its populated with "http/1.1" instead of the empty string. Unfortunately it was not possible to writes for the other attributes since we do not currently have the ability to test against an http2 server. Both `wasFetchedViaSpdy` and the devtools output effectively need an http2 server to observe differences. These parts of the CL were manually tested. Bug: 1069813 Change-Id: I84819ef5a53e9246f9e383e56b6d7e5901a7a243 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143860 Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Ben Kelly <[email protected]> Cr-Original-Commit-Position: refs/heads/master@{#770192} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: e8826733cdcc059cac5fb884f6456af23ff0aff2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expressing RT in terms of Fetch will force us to clarify a lot of the current edge cases:
Some ideas on mechanics of how to accomplish this in #36 (comment). This will be a substantial effort with required changes both in RT and Fetch specs.
The text was updated successfully, but these errors were encountered: