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

Ryan Hamilton <> Tue, 13 March 2018 00:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 909B0126D45 for <>; Mon, 12 Mar 2018 17:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YIpqeR6ZAcj for <>; Mon, 12 Mar 2018 17:26:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 212A51250B8 for <>; Mon, 12 Mar 2018 17:26:38 -0700 (PDT)
Received: by with SMTP id p129so1526203ywh.9 for <>; Mon, 12 Mar 2018 17:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYRrIockTMNQSVowBILSxSf7ic7GbzarOaqBVUNOTTY=; b=Zrykgb/OXnFF2musjFeZL/VvTSM5s4CDwcbwJri4lVzdSVlQ/9XxnonKn/GjYwX/AW 4zoWc6HyQVysdGqxNbSwZkFa3icqVAHD/rdxZKooQSb1SYoGqweJ3Fa3AnjBXe/YOAkD DzYmUF4wAzqvpdmmJisFaQ1AJLR1MGP3qxumtj6rWlokH/BaRD5QSqB+Xzr18mCG3xJF Qn92Z2BtSLJYfLErzrA7uGfspyCtMNFGwtOjhb4eH7ZYtDpJwIGo19D6KkyNHaknLSZC QNt2GTMtGvgCsmERAMN7gWTpdSm/D4xrasViQsQ4Z2S1mPByiH/5AE5y5D7Zd13iSvVJ eZ/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AYRrIockTMNQSVowBILSxSf7ic7GbzarOaqBVUNOTTY=; b=JLqSgCYHKDHTRxESApCVxbQd25vBkclfIsUu8xHtsMGx57uZkRIPkwi4uFVudRE1Ux odHqFRSqD9hMcs4sELyvcS3LmIhw3V78eA7uZRxkchI3N16GX2KjEHD3RHl/xFizyYE3 wUxILcSaLqMghNgBP5+Lcllsr6T4Ph7giaY2EuAY1kV92oEqg1eEe6IAyEBVHqE36yFm LLsVTU7azBWq9ofW5KWrJJZY+uWwaBvKDe6ReY70MjK2dGOrxDPfrlISP9L5wBYyGVx8 jenrVfoQrtPsqaMvif9N69jQt7IDOkrBzxEb/ZntagFTLT6KrplL6W2+MPNT0ocrGo6i Vnjg==
X-Gm-Message-State: AElRT7Fogu1S/7gMcjybHLjQSKtRhBqbk70aIYae+NpJpEu3MDxiK5/A FeFlwBi3urHgjkLvz1AuheqheYjfJgsZ0QPy6hLuZw==
X-Google-Smtp-Source: AG47ELtH/fjDXF0cUsEAtNnlb4+PF0uUF9ywlHODj09nuBAU8kaghPs7ioolwnspSqPfi55Gmy/VMJHJkQpOR4xm31s=
X-Received: by 2002:a25:cd84:: with SMTP id d126-v6mr5727465ybf.314.1520900796821; Mon, 12 Mar 2018 17:26:36 -0700 (PDT)
MIME-Version: 1.0
References: <7CF7F94CB496BF4FAB1676F375F9666A3BB069BA@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB069BA@bgb01xud1012>
From: Ryan Hamilton <>
Date: Tue, 13 Mar 2018 00:26:26 +0000
Message-ID: <>
Subject: Re: resourceTiming.nextHopProtocol reports"hq" - is that ok?
To: Lucas Pardue <>
Content-Type: multipart/alternative; boundary="000000000000bc67220567404fd5"
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: Tue, 13 Mar 2018 00:26:41 -0000

Just for reference, here's 2.1.1:

   For example, suppose a server supported both version 0x00000001 and
   the version rendered in ASCII as "Q034".  If it opted to include the
   reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and
   0x1abadaba, it could specify the following header:

   Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0"

That suggests that if a server want to advertise HTTP over Google QUIC
Q034, it can use "hq" in the advertisement. Perhaps that's not the intent?

In any case, if we think that "hq" is the wrong identifier to be using in
the resource timing API, it would probably be a good idea for the WG to
clarify the issue with the w3c since I believe that's what drove the chrome



On Mon, Mar 12, 2018, 4:37 PM Lucas Pardue <> wrote:

> Hi,
> 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?
> Background
> ========
> 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-
>    01".
> (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
> Lucas
> [1]
> [2]
> -----------------------------
> 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
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------