Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#2574 closed defect (invalid)

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

Reported by: Itai Segev Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.23.x
Keywords: Cc: Itai Segev
uname -a: Linux f9ae48be22b0 5.15.49-linuxkit-pr #1 SMP Thu May 25 07:17:40 UTC 2023 x86_64 Linux
nginx -V: nginx version: nginx/1.23.3


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");
  1. 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.

Change History (4)

comment:1 by Maxim Dounin, 4 months ago

Resolution: invalid
Status: newclosed

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.

comment:2 by Itai Segev, 4 months ago

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?


comment:3 by Maxim Dounin, 4 months ago

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).

comment:4 by Itai Segev, 4 months ago

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


Note: See TracTickets for help on using tickets.