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
