Welcome! Log In Create A New Profile

Advanced

Re: extension to server_name directive - include top-level directory in search

Maxim Dounin
July 25, 2023 04:02PM
Hello!

On Tue, Jul 25, 2023 at 07:56:50AM -0700, Chris Newton via nginx-devel wrote:

> The server_name directive allows for selecting which "server" block should
> be used to process a request; a "server" being a very convenient way to
> group a set of directives and location blocks into a separate and distinct
> configuration entity. Currently, server_name selects the server based on
> the value of the Host: header alone, which can be overly constraining.
>
> The attached patch extends server_name to allow the first directory element
> to be used as part of the selection process. When there is at least one
> server_name with a '/' character, at ngx_http_find_virtual_server() time an
> initial lookup into the virtual_names hash is made using a combination of
> hostname/topleveldirectory - if no match is found, the hostname only lookup
> is performed (as before), thereby allowing for specific directories to be
> broken out into their own server blocks

This somewhat contradicts the configuration model as currently
used in nginx: for different name-based virtual hosts, "server"
blocks are used as a basic configuration entity, and for different
URI prefixes within these virtual hosts there are "location"
blocks.

With the change suggested, these are combined into multiple
"location-based-server" blocks, and I see at least the following
issues with this approach:

- It would be really non-trivial to find out how a particular
request is handled when looking into a configuration. In
particular, even with the Host name explicitly known, full nginx
configuration would be needed to find out correct "server"
block.

- There will be at least three different server blocks involved
during a request handling: the default one for a listening
socket (for early connection-specific options), the default one
for a host (for connection-specific options after SNI name is
know), and the one matched for a request URI.

Also, I see at least the following issues in the implementation:

- The code uses the ngx_http_uses_complete_alias global variable,
which is set during configuration parsing. This is not going to
work in general, for example, the global variable will be
incorrect on a worker process respawn after configuration parsing
errors.

- Handling assumes that r->uri for a request is available during
the ngx_http_find_virtual_server() call, which might not be the
case, for example, for HTTP/2, since order of pseudo-headers is
not guaranteed.

Overall, a better idea might be to focus on what's the problem you
are trying to solve, and how to solve it within nginx
configuration model.

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

extension to server_name directive - include top-level directory in search

Chris Newton via nginx-devel 233 July 25, 2023 10:58AM

Re: extension to server_name directive - include top-level directory in search

Maxim Dounin 82 July 25, 2023 04:02PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 271
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready