Re: Questions on HTTP URI schemes and QUIC

Martin Thomson <> Wed, 25 July 2018 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCB64130E48 for <>; Tue, 24 Jul 2018 23:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 WhSS8Z4eD_CY for <>; Tue, 24 Jul 2018 23:59:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FCE7130E2C for <>; Tue, 24 Jul 2018 23:59:55 -0700 (PDT)
Received: by with SMTP id n84-v6so12019674oib.9 for <>; Tue, 24 Jul 2018 23:59:55 -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:content-transfer-encoding; bh=5ov0kZmwOFnxR/33//Sek+BJ3mIXswJIUv/aYo0Xk1E=; b=Z6b92+9OCS6I0y5VD3ECM6UMCJtYUH62cpeg5h2o8gYyX1+q3OtcvVMrOWASJk2NDQ dS4HvP51w2IHI8BIQL7J3GWoKAlDnJCPoPPih21NV8k+WC2lcJrucK29OJR/B4FNXnEE 05tBVtaeo0bb/8fqM8O7fgOkhW7DO94cSFVBTuDXCkcySF4qmSUaARkXboIqWS93mtNV /gCad/VbrzFrm62EuDwSeJaWNWPa2kewBTWu85E4K6M10paXZklPvkBTISXKZvzR4y1K FjxIyr49Uyc1GfShVYzhbD66gCCW8/wZ5bv0Ngz3VFyz7by7KTdL/uzA+9i49JZkA34r xIfA==
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:content-transfer-encoding; bh=5ov0kZmwOFnxR/33//Sek+BJ3mIXswJIUv/aYo0Xk1E=; b=IMxWJJNlOZwMmEkUH8ft/iFhGEAVP2EYMhxiyFIN/GJhIS0wsUVwNV3wiX5+N6Ie3T SNw/ziPKXtF1KgZdBe9UUQjD0nQII5NJ0j4TGDFSlHhdroM7lrOc5yVwIaTV/YycT1xZ u2FrkYJWNIY1Lo+BHSjHbIxFWyX0/qErNBWZ845Y86nexg9KO9gJjyCkfYezwr6DAWUk iVma6jEwabUhblFWS8uuerH2CrNceGi07LxCnxvzMpNcVeVvU6yrOhl8utn8TlGM8C6O pyoxrmEg/VWL6BJ3mlQZ/DHZXvbJJ3P0W2Y/MHeWczRAWueqS8pEGYOFw/vGmzv5VB/d OoCw==
X-Gm-Message-State: AOUpUlGXYjO4PxPEh3aT5jrGqWfKBiQXfZZJS9xaNsWH87fOHdJ+rbBU LsqcU+DH8XEBSanYLgEUdOEEFgNWazsnoI4Dvr0=
X-Google-Smtp-Source: AAOMgpeHgVEMoqwW1hakKAdynhsWFAsvPwwDCWw3QT/hOlSYXlqgnHlniNYYwFwRQTP4mcjkidElal//nMbcEirZKWM=
X-Received: by 2002:aca:b208:: with SMTP id b8-v6mr2084316oif.144.1532501994384; Tue, 24 Jul 2018 23:59:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <> <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 25 Jul 2018 16:59:43 +1000
Message-ID: <>
Subject: Re: Questions on HTTP URI schemes and QUIC
Cc: Ted Hardie <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.27
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: Wed, 25 Jul 2018 06:59:57 -0000

On Wed, Jul 25, 2018 at 1:34 PM Sridhar Bhaskaran
<> wrote:
> If the client is configured to route the request via a proxy (configuration is at HTTP level and application is unaware of it), then what should be the ":authority" pseudo header in a HTTP/2 request (i.e the authority part of the URI)?

Yes, this is as defined in RFC 7540.  The identity of the proxy
doesn't matter.  Of course, that places a lot of trust in the proxy,
and clients rarely do that.  In most cases, a (forward) proxy will
instead see a CONNECT request instead.  (I'm assuming HTTPS here, as
deployment of unsecured HTTP/2 is both effectively non-existent and
prohibited by 3GPP.)

> If the authority part of the URI still refers to an FQDN / IP address of the HTTP server, then isn’t the TLS certificate exchange supposed to happen against this? On the other hand, if the authority part of the URI refers to the proxy's endpoint itself, then how does the proxy know where to route the request further?

The latter is what we call a reverse proxy or gateway.  For that to
work, the "proxy" needs to hold a certificate and keys that are valid
for the identified authority.  The proxy can usually only operate for
a single authority for each connection (RFC 7540 covers the exceptions
to this).  It can use the TLS server_name extension and HTTP Host
header field to demultiplex requests for multiple names if it is
authoritative for more than one.  Each name typically needs a separate

> By the way are there any IETF drafts / RFCs that explain how this would work?

RFC 7540 should describe most of this, either directly or by
reference.  TLS server_name is described in RFC 6066.