nixos/nginx: add option typesHashMaxSize

[Izorkin]

Description of changes

Allow to change maximum size of the types hash tables.
It is recommended to reduce the size if a custom file with mime-types is used.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[pbsds]

It is recommended to reduce the size if a custom file with mime-types is used.

source?

This strikes me like the kinda thing that explodes at runtime, not build/eval time. Can this be added to the tests?

[SuperSandro2000]

I think we should move this into a let in and deduplicate with the other option to prevent it accidentally getting out of date.

[Izorkin]

The mime.types file is rarely updated. If it is, the test will show that a change will be required.

[fpletz]

Do you mean defaultText? That option is in the very next line.

[Izorkin]

source?

https://nginx.org/en/docs/hash.html

This strikes me like the kinda thing that explodes at runtime, not build/eval time. Can this be added to the tests?

I'll see what I can do.

[Izorkin]

Updated test.

[pbsds]

I played a bit around with this.
If set to 1024:

vm-test-run-nginx> subtest: check optimal size of types_hash
vm-test-run-nginx> webserver: must fail: journalctl --unit nginx --grep 'could not build optimal types_hash'
vm-test-run-nginx> Test "check optimal size of types_hash" failed with error: "command `journalctl --unit nginx --grep 'could not build optimal types_hash'` unexpectedly succeeded"

if set to 4096, it passes.

if set to 16400, it passes.

How did you arrive at 2688? Is there any way to test for the max_size being too big? (assuming there is a performance penalty for that)

[Izorkin]

How did you arrive at 2688? Is there any way to test for the max_size being too big? (assuming there is a performance penalty for that)

I adjusted the parameter manually, in increments of 64 and the current mime.types file in the mailcap package.
If use a smaller mime.types file, the types_hash_max_size can be reduced.

[pbsds]

LGTM, i leave it to code-owner to decide if the typesHashMaxSize limit should be this tight, and whether the types_hash test should be a (i assume) release blocker.

[Izorkin]

cc @RaitoBezarius @fpletz

[fpletz]

LGTM. I think we don't need the nginx test to be a release blocker since this technically doesn't render nginx to be broken. It should only incur a small performance hit. The failing test should be enough to cover this.

[Izorkin]

@fpletz is that an variant?

[fpletz]

@fpletz is that an variant?

Sorry, I didn't mean any change by my review. I'm fine with either the nginx test standalone or having the nginx test in mailcap. My only intention with the review was to convey that the nginx test doesn't need to be a release blocker - if anybody feels otherwise I'm also fine with that.

[Izorkin]

Updated and rebased PR.