core module "ngx_http_set_etag" function doesn't set etag lowcase_key field.

[Itai Segev]

In nginx-1.23.3/src/http/ngx_http_core_module.c , "ngx_http_set_etag" function adds the "ETag" header to response but does not initialize the header lowcase_key par: "etag->lowcase_key" and not nullify it either so we can't null-check it and know if it is unset in our module code.

I suggest to initialize the lowcase_key while initializing "etag" variable in "ngx_http_set_etag" function and have two options for that

1. etag->lowcase_key= ngx_pnalloc(r->pool, strlen("etag") + 1); strcpy((char*) etag->lowcase_key, "etag");

2. etag->lowcase_key=(u_char*)"etag"; r->headers_out.etag = etag;

I think the first option is safer because we don't cast the string literal const to u_char*

If for some reason bug reviewer thinks we shouldn't init the lowcase_key just nullifying will also help.

[Maxim Dounin]

This behaviour matches other headers in r->headers_out: these are not expected to have lowcase_key set or hash correctly calculated. For some examples, consider:

• the Location header as added by the static module to directory redirects, see ​here;
• the Accept-Ranges and Content-Range headers as added by the range filter module, see ​here;
• the Expires header added by the expires directive and arbitrary headers as added by the add_header directive, see ​here;
• arbitrary headers as added by the $r->header_out() method of the embedded perl module, see ​here;
• and so on.

For more examples, try grep -r 'ngx_list_push(&r->headers_out.headers)' src/.

If you think you need lowcase_key field on the response headers for some reason, you may want to describe what you are trying to do in the ​nginx-devel@ mailing list and ask for recommendations.

[Itai Segev]

Hi. Thanks for your response and additional information!
I understand now that usage of lowcase_key is not common for response headers and we do need it for a module we write that sends response headers to some external processor and we need those headers in lowcase (for HTTP/2 standard).

What about just nullifying those lowcase_key so it will be possible to check that lowcase_key is for sure not initialized?

Thanks,
Itai.

[Maxim Dounin]

As already outlined in comment:1, as of now the lowcase_key field for output headers is not required to be set to anything meaningful, and changing this would mean an API change (with highly questionable benefits). I would not expect this to happen anytime soon.

If you need to use a lowercased version of the header, consider using key with appropriate mapping, such as nginx HTTP/2 module does (see ​here).

[Itai Segev]

Ok, so I will treat all headers.out headers to not have valid lowercase_key.
Should I also expect all the headers.in to have valid lowercase_key then?

Thanks.