[PATCH] fastcgi_params: added REMOTE_HOST parameter

[Maxim Dounin]

Hello!

On Fri, Jan 12, 2024 at 11:03:45PM +0000, Jakub Zelenka wrote:

> On Fri, Jan 12, 2024 at 10:20 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > > # HG changeset patch
> > > # User Jakub Zelenka <bukka at php.net>
> > > # Date 1705078404 0
> > > #      Fri Jan 12 16:53:24 2024 +0000
> > > # Node ID 1ff2f737bd318a730d0944a6037c8fd7c7da2656
> > > # Parent  ee40e2b1d0833b46128a357fbc84c6e23be9be07
> > > Added REMOTE_HOST parameter to fastcgi_params.
> > >
> > > When HTTP/3 is used, users will no longer get HTTP_HOST as host header
> > is no
> > > longer set by most clients. It is useful / necessary for many setups to
> > have
> > > such information and REMOTE_HOST is defined in CGI/1.1 for such purpose.
> >
> > https://datatracker.ietf.org/doc/html/rfc3875#section-4.1.9
> >
> >    The REMOTE_HOST variable contains the fully qualified domain name of
> >    the client sending the request to the server, if available, otherwise
> >    NULL.
> >
> > That is, REMOTE_HOST is completely unrelated.  It is not the
> > hostname of the requested server, but the hostname of the client -
> > result of a reverse DNS lookup of a client's IP address, something
> > used to be provided by some servers when Internet was small (e.g,
> > HostnameLookups in Apache).  It is certainly not the right param
> > to use for $host.
> >
> >
> I think you are right. I somehow thought about nginx as a client for some
> reason (technically it's a client from FPM point of view) but I agree that
> the meaning is different here.
> 
> > IMO, proper param to use would be SERVER_NAME.  It is set to
> > $server_name by default, though can be modified locally to provide
> > $host if needed in the particular configuration.
> 
> I think it's probably the best option. Although current default value is a
> bit unfortunate as it's just server_name specified by user so most of the
> time is meaningless. Not sure if it can really comply with linked RFC
> either as it doesn't have to be hostname. On the other side it's been
> default for ages so I guess it won't be changed, right?

Well, $server_name is actually expected to be a proper/canonical 
name of the server.  In particular, it is used by nginx itself 
when returning redirects with "server_name_in_redirect on;" (used 
to be the default, but not anymore, since the default server_name 
was changed to "" in nginx 0.8.48).

I believe it is up to the particular server configuration if 
SERVER_NAME should be set to $server_name, that is, the canonical 
name of the server, or should use $host, as might be preferred in 
more dynamic configurations where multiple names are handled in a 
single server{} block or when server_name is not set at all.

Changing the default as provided in various fastcgi_param files as 
shipped with nginx might be indeed troublesome though.  For 
example, if a configuration expects SERVER_NAME to be a canonical 
name, changing SERVER_NAME to client-controlled $host might result 
in security issues.

> It's all just a bit unfortunate because with HTTP/3, there is no longer any
> server host info in the default configuration that would be passed to FPM.

The "Host" header is not required to be present in HTTP/1.x 
either, and even in HTTP/1.1 where it is required to be present, 
it might not match the authority actually requested via the 
request line.  That is, technically using the "Host" header for 
anything, except might be links sent to the client itself, is 
almost always wrong.

OTOH, for HTTP/2 nginx emulates the "Host" header based on the 
":authority" pseudo-header.  Given the amount of pain the approach 
taken for HTTP/3 causes, we might consider doing the same for 
HTTP/3 as well.

-- 
Maxim Dounin
http://mdounin.ru/