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

[Maxim Dounin]

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/