Re: [quicwg/base-drafts] Authoritative access in HTTP/3 (#3558)

Mike Bishop <> Wed, 01 April 2020 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C88603A10A7 for <>; Wed, 1 Apr 2020 07:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h0k_AwvJN0CD for <>; Wed, 1 Apr 2020 07:55:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A92F03A10A4 for <>; Wed, 1 Apr 2020 07:55:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F3F0A1C0503 for <>; Wed, 1 Apr 2020 07:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585752916; bh=CfCeJDQv8GiU50ViwWh9EspmqHWS0Bne+9QSrZ34+KQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iXMQuGncvQHGqj4M/yZhNb7UsxqexTZmRDrqXF8JnpWB49miIEhlOxiN329hR4iWS mRIp9ul0EqLlMthWXDxAJ5skUvO6ah40w/AjlVF8h+ghFmNorg86xUraC08dIomiZX nlAglZYUOOikgqxUZNwbivsnirxR8FOlMFLDQ94M=
Date: Wed, 01 Apr 2020 07:55:16 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3558/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Authoritative access in HTTP/3 (#3558)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e84ab54e53f1_59b13fc767acd96018345b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2020 14:55:20 -0000

@MikeBishop commented on this pull request.

> +private key associated with a certificate that the client considers to be
+trustworthy for the host identified by the authority component of the URL. If a
+server presents a certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+Connectivity problems (e.g., firewall blocking UDP) can result in QUIC
+connection establishment failure; clients SHOULD attempt to use TCP-based
+versions of HTTP in this case.

I think this statement is still sufficient, since any TCP-based version of HTTP will tell you to use TLS for an "https" URL.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: