Re: What is the HTTP/1.1 equivalent of ":scheme" in HTTP/2 and HTTP/3?

Hi,

On Wed, Mar 22, 2023 at 10:13:53AM +0800, Jingcheng Zhang wrote:
> On Wed, Mar 22, 2023 at 4:28 AM Martin Thomson <mt@lowentropy.net> wrote:
> 
> >
> > In HTTP/1.1, scheme can be explicit if the authority form is used.
> > However, in most cases the scheme is inferred from properties of the
> > connection.  That is, if TLS is in use, infer "https"; otherwise, infer
> > "http".
> >
> >
> The gateway text covers those cases where you have cleartext to the gateway
> > and TLS to an origin server (not that common now) or the scary case of TLS
> > to the gateway and cleartext to the origin (shockingly, still more common
> > than I'd like).  In those cases, the gateway might use absolute form as you
> > say.  Forwarded-For (https://www.rfc-editor.org/rfc/rfc7239#section-5.4)
> > has a parameter that might signal this.
> >
> > Signals might also be implicit - if there is only an "http" front end, the
> > origin server can assume "http" even when the request from the gateway
> > comes in over TLS.  That's probably very common as it is increasingly less
> > common to have both "http" and "https", as the latter is superior in nearly
> > every way.
> >
> >
> Got it, thanks for your detailed explanation. So the absolute-form can be
> explicitly used, but RFC 9112 (HTTP/1.1) says it is intended to be used for
> sending requests to proxies, although origin servers are required to
> support it. This is in fact not exactly equivalent to ":scheme", as
> ":scheme" has no restrictions. Am I right?

It is the exact equivalent. In H2 (and H3) the pseudo headers are used
to split the request or response line into individual fields and mostly
use absolute requests since there's no need for on-wire compatibility
with HTTP/0.9 or 1.0. As such, requests simply provide the contents that
you normally find in an absolute URI split into :method, :scheme,
:authority, :path, and the response contains :status (and the version
and reason are dropped since useless).

The only difference is that in HTTP/1 as you say, origin-form is the
most common and in this case there is no scheme. However in this case,
the server *knows* what scheme is being used by configuration, because
a combination of listener port + clear/TLS implies a scheme for a given
configuration.

Typically if you're forwarding HTTP/1 over HTTP/2 you have to present
a scheme that in fact reflects the processing that is applied on the
HTTP/1 listener.

Hoping this helps,
Willy

Received on Wednesday, 22 March 2023 07:17:18 UTC