commit ca0b9b08b4e1f770ffa7722b730a712da379722f
author Ben Kelly <wanderview@chromium.org> Tue May 19 18:45:16 2020
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Tue May 19 19:05:15 2020
tree 53b988d79b34030c1122f1ca4a91cfea8211b9bb
parent 27e994b5ba6e98da63fae9beb50930c61709f221

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:

https://github.com/w3c/resource-timing/issues/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 <jbroman@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Ben Kelly <wanderview@chromium.org>
Cr-Commit-Position: refs/heads/master@{#770192}