RE: resourceTiming.nextHopProtocol reports"hq" - is that ok?


Thanks for being so responsive to this issue. Looking forward to testing some future version of Chrome.

Kind regards
From: Ryan Hamilton []
Sent: 14 March 2018 22:57
To: Martin Thomson
Cc: Amos Jeffries; HTTP Working Group
Subject: Re: resourceTiming.nextHopProtocol reports"hq" - is that ok?

On Tue, Mar 13, 2018 at 1:05 AM, Martin Thomson <<>> wrote:
On Tue, Mar 13, 2018 at 4:46 AM, Amos Jeffries <<>> wrote:
> On 13/03/18 16:56, Ryan Hamilton wrote:
> For informing the recipient of any additional versions of QUIC which the
> sender supports. At present it could be referring to older Drafts which
> are still supported (but not preferred), and after RFC publication to
> different versions of the "hq" protocol (if any).

Everything Amos said here.  Remember that there are two versions in
play here: QUIC and HTTP over QUIC.  And using "hq" camps on a value
we intend to use.  If Google are indeed using it, then it might
already be unrecoverable, but that depends on how thoroughly it can be

If this use of "hq" continues - even in part - then we'll have to pick
a different value for HTTP over QUIC.

The actual ALPN that Google QUIC uses is unlikely to matter in the
long term, but I would use hq-00, even if it has diverged from that
since the -00 drafts went out.

​As discussed in-person, the current use of "hq" by Google shouldn't cause long term harm because it's used in conjunction with a quic​= list that only includes google QUIC versions.

That being said, I'm happy to change this. We've disabled the experiment in Chrome which thinks in understands "hq" in an Alt-Svc advertisement and we'll also disable the server-side announcement. In addition, I've updated the w3c issue about nextHopProtocol and have sent off a Chrome code review to change the resource timings API output which kicked off this thread.



Received on Thursday, 15 March 2018 00:31:22 UTC