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

On Tue, Mar 21, 2023, at 20:27, Jingcheng Zhang wrote:
> HTTP/2 and HTTP/3 have defined ":scheme" to carry the scheme 
> information of target URI, however I haven't seen any fields in 
> HTTP/1.1 that carry the same information. RFC 9112 (HTTP/1.1) says:
>
> If the server's configuration provides for a fixed URI scheme, or a 
> scheme is provided by a trusted outbound gateway, that scheme is used 
> for the target URI. This is common in large-scale deployments because a 
> gateway server will receive the client's connection context and replace 
> that with their own connection to the inbound server. Otherwise, if the 
> request is received over a secured connection, the target URI's scheme 
> is "https"; if not, the scheme is "http". 
>
> It says "or a scheme is provided by a trusted outbound gateway", but 
> how do gateways provide the scheme information to backend servers? I 
> know HTTP/1.1 absolute-form can carry this information, is it the 
> suggested way? Or are there any registered fields?

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.

Received on Tuesday, 21 March 2023 20:24:45 UTC