Second parameter to fancyindex_header/fancyindex_footer is not always optional

[cschug]

I just gave version 0.5.0 a spin but my configuration breaks with following error message:

# nginx -t
nginx: [emerg] unknown header/footer kind "/tools/memdisk" in /etc/nginx/nginx.conf:107
nginx: configuration file /etc/nginx/nginx.conf test failed

if the order of directives is like that

fancyindex_footer               "/fancyindex/footer.html";
fancyindex_header               "/fancyindex/header.html" subrequest;

If I swap those lines, the configuration validates and loads (init issue?).

And the even more curious thing is that /tools/memdisk mentioned in the error message isn't even part of the server stanza where fancyindex is being used. But it is rather the last location of the server stanza defined before the server in question. I have no idea how Nginx works internally but this seems off-by-one if all locations are indexed sequentially.

This is Nginx 1.18.0 (self-compiled) on a CentOS 8 box. For now I will always specify the second parameter.

[bubbleatgit]

I have solved the problem.

This is my config:

    fancyindex_header "/fancy-index/before.html" subrequest;
    fancyindex_footer "/fancy-index/after.html" subrequest;

look this snippet:

ngx-fancyindex/ngx_http_fancyindex_module.c

Lines 231 to 240 in f52bace

	/* Kind of path. Default is "subrequest". */
	ngx_uint_t kind = NGX_HTTP_FANCYINDEX_HEADERFOOTER_SUBREQUEST;
	if (cf->args->nelts == 2) {
	kind = headerfooter_kind(&values[2]);
	if (kind == NGX_CONF_UNSET_UINT) {
	ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
	"unknown header/footer kind \"%V\"", &values[2]);
	return NGX_CONF_ERROR;
	}
	}

[aperezdc]

This is definitely a bug. The intention was to make subrequest optional to not break people's configuration files, but it seems that I did not write the config file handling correctly. I'll take a look at put out a 0.5.1 release as soon as I have a fix.

[aperezdc]

@cschug @bubbleatgit: release 0.5.1 is now available, and it includes the fix for this bug.

[cschug]

@aperezdc LGTM, both issues, the optionalness of the second parameter as well as the error reporting in case of a unknown header/footer kind are fixed in 0.5.1. Thanks a lot for this quick fix and overall for this really, really helpful module ... very much appreciated!