# HG changeset patch
# User Alexey Radkov <alexey.radkov@gmail.com>
# Date 1629395487 -10800
# Thu Aug 19 20:51:27 2021 +0300
# Node ID a1065b2252855730ed8e5368c88fe41a7ff5a698
# Parent 13d0c1d26d47c203b1874ca1ffdb7a9ba7fd2d77
Avoid unnecessary restriction on nohash http variables.

When I use variables with long names albeit being tagged as
NGX_HTTP_VARIABLE_NOHASH, Nginx says "could not build variables_hash,
you should increase variables_hash_bucket_size: 64". It seems that this is
an unnecessary restriction, as soon as the hash gets only built for variables
with names[n].key.data == NULL (note that other pieces in ngx_hash_init()
where the macro NGX_HASH_ELT_SIZE is used, are always guarded with this
condition). This fix puts this same condition into the only unguarded piece:
when testing against the hash_bucket_size.

The issue arises after assignment of key[n].key.data = NULL without symmetric
assignment of key[n].key.len in ngx_http_variables_init_vars(): after this,
the key[n].key comes to an inconsistent state. Perhaps this was made
intentionally, as hash initialization in other places seems to follow the
same pattern (for instance, see how ngx_hash_init() gets called from
ngx_http_upstream_hide_headers_hash()).

Without this fix, I must put in the config "variables_hash_bucket_size 128;"
even if the long-named variables are nohash.

diff -r 13d0c1d26d47 -r a1065b225285 src/core/ngx_hash.c
--- a/src/core/ngx_hash.c Fri Aug 13 03:57:47 2021 -0400
+++ b/src/core/ngx_hash.c Thu Aug 19 20:51:27 2021 +0300
@@ -274,6 +274,9 @@
}

for (n = 0; n < nelts; n++) {
+ if (names[n].key.data == NULL) {
+ continue;
+ }
if (hinit->bucket_size < NGX_HASH_ELT_SIZE(&names[n]) + sizeof(void *))
{
ngx_log_error(NGX_LOG_EMERG, hinit->pool->log, 0,

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel