Re: Questions on HTTP URI schemes and QUIC

[Martin Thomson <[e-mail]>]

On Wed, Jul 25, 2018 at 1:34 PM Sridhar Bhaskaran
<[e-mail]> 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
connection.

> 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.