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

Lucas Pardue <> Mon, 12 March 2018 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C07D21250B8 for <>; Mon, 12 Mar 2018 16:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XlsqesTBOc_u for <>; Mon, 12 Mar 2018 16:37:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDC99124F57 for <>; Mon, 12 Mar 2018 16:37:07 -0700 (PDT)
Received: from ([]) by (8.15.2/8.15.2) with ESMTP id w2CNb53N002506; Mon, 12 Mar 2018 23:37:05 GMT
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Mon, 12 Mar 2018 23:37:03 +0000
From: Lucas Pardue <>
To: IETF QUIC WG <>, HTTP Working Group <>
Subject: resourceTiming.nextHopProtocol reports"hq" - is that ok?
Thread-Topic: resourceTiming.nextHopProtocol reports"hq" - is that ok?
Thread-Index: AdO6WIinTkcO+1BmSJGI76rLGUAkIQ==
Date: Mon, 12 Mar 2018 23:37:02 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB069BA@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-originating-ip: []
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--14.127600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Mar 2018 23:37:10 -0000


TL;DR is that I see Chrome 64+ report the ALPN ID "hq" when I retrieve protocol information in client-side JavaScript. Is this ok?

I was playing around on my site which talks GQUIC 39, advertised with the Alt-Svc ALPN ID "quic".

My website previously used chrome.loadTimes() to detect the protocol, however things have moved on and now Chrome suggests I use  resourceTiming.nextHopProtocol() instead . So I updated my client code and was surprised to see that it now reports that I am talking "hq", rather than the previous string "http2+quic/39".

I created a thread on Google's proto-quic group [1] but Ryan Hamilton and I seem to disagree. Our discussion suggests that draft-ietf-quic-http-10 is a bit ambiguous, section 2.1.1 and 2.2.1 seem to be at odds. Ryan also kindly pointed out a w3c issue that touched on this topic [2].

Section 2.2.1 says:

   Only implementations of the final, published RFC can identify
   themselves as "hq".  Until such an RFC exists, implementations MUST
   NOT identify themselves using this string.

   Implementations of draft versions of the protocol MUST add the string
   "-" and the corresponding draft number to the identifier.  For
   example, draft-ietf-quic-http-01 is identified using the string "hq-

(FWIW, In the wild I see lots of "hq" being advertised, which seems to break this rule. )

So, is it ok to report "hq" in this case?

In my opinion, it would be really helpful to expose more information than just "hq" to JavaScript. As Yoav points out on [2], reducing fidelity of this data makes my life as a site operator harder when trying to gather protocol-related metrics.

Kind regards


This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to