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

Maxim Dounin mdounin at mdounin.ru
Tue Jul 25 20:00:53 UTC 2023


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" 

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" 

- 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 

- 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

More information about the nginx-devel mailing list