[PATCH] fastcgi_params: added REMOTE_HOST parameter

[Jakub Zelenka]

Hi,

On Sat, Jan 13, 2024 at 3:14 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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).
>
>
Yeah that's exactly the thing. Lots of configurations just have empty
string or "_" to make it more generic.


> 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.
>
>
The problem is that most users will just need to spend time to figuring
that out so it makes switch to HTTP/3 more difficult for them.


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

Yeah agreed that could do more harm than good.


>
> > 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.
>
>
True but it's still most of the time enough for the applications to do the
right thing which works for normal users - e.g. apply the right app
configuration.


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

 I think this would be great and probably the best option. It would safe
time to many users and maintainers as I'm sure there will be more users
asking for it as soon as HTTP/3 becomes more in use.

Cheers

Jakub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20240117/db96250c/attachment.htm>