Instead of conditioning the use of defaultMimeTypes on the custom mime-types being empty, would it make sense to make defaultMimeTypes nullable?

If defaultMimeTypes is not disabled then new types will be added to existing types and cannot be changed.

The defaultMimeTypes parameter was added in an attempt to reassign to a new list of mime-types in the future, but failed to add the media-types package.

A common use case I see is that one would like to keep the default mime-types, but add one or two additional file types.

A common use case I see is that one would like to keep the default mime-types, but add one or two additional file types.

Add another parameter addMimeTypes? Or the ability to specify to use null for defaultMimeTypes?

This is what i envison:

In addition to defaults:

{ services.nginx = {
    mimeTypes."model/stl" = [ ".stl" ];
}; }

Replacing defaults:

{ services.nginx = {
    defaultMimeTypes = null;
    mimeTypes."model/stl" = [ ".stl" ];
}; }

with a warning in mimeTypes.description that conflicts with defaultMimeTypes are to be expected.

This is only my preference however, and maybe code-owner @RaitoBezarius have a different opinion

Perhaps renaming defaultMimeTypes to mimeTypeIncludeFiles, and make it a listOf path?

Allow this variant?

diff --git a/nixos/modules/services/web-servers/nginx/default.nix b/nixos/modules/services/web-servers/nginx/default.nix
index f523833e5b66..5b425c147b6d 100644
--- a/nixos/modules/services/web-servers/nginx/default.nix
+++ b/nixos/modules/services/web-servers/nginx/default.nix
@@ -128,6 +128,10 @@ let
     }
   ''));

+  addMimeTypeConfig = lib.concatLines (flip mapAttrsToList cfg.addMimeTypes (addMimeType: extensions: ''
+    ${addMimeType} ${concatStringsSep " " extensions};
+  ''));
+
   mimeTypeConfig = lib.concatLines (flip mapAttrsToList cfg.mimeTypes (mimeType: extensions: ''
     ${mimeType} ${concatStringsSep " " extensions};
   ''));
@@ -136,7 +140,10 @@ let
       # Load mime types.
       default_type application/octet-stream;
       ${optionalString (cfg.mimeTypes == {}) "include ${cfg.defaultMimeTypes};"}
-      ${optionalString (cfg.mimeTypes != {}) "types {\n${mimeTypeConfig}\n}"}
+      ${optionalString (cfg.mimeTypes != {} || cfg.addMimeTypes != {}) "types {\n"}
+      ${optionalString (cfg.addMimeTypes != {} && cfg.mimeTypes == {}) "${addMimeTypeConfig}"}
+      ${optionalString (cfg.mimeTypes != {}) "${mimeTypeConfig}"}
+      ${optionalString (cfg.mimeTypes != {} || cfg.addMimeTypes != {}) "\n}"}
       # When recommendedOptimisation is disabled nginx fails to start because the mailmap mime.types database
       # contains 1026 entries and the default is only 1024. Setting to a higher number to remove the need to
       # overwrite it because nginx does not allow duplicated settings.
@@ -646,6 +653,19 @@ in
         '';
       };

+      addMimeTypes = mkOption {
+        type = with types; submodule {
+          freeformType = types.attrsOf (types.listOf str);
+        };
+        default = {};
+        example = literalExpression ''
+          "model/stl" = [ "stl" ];
+        '';
+        description = ''
+          Enabling custom mime types to an existing list {option}`services.nginx.defaultMimeTypes`.
+        '';
+      };
+
       mimeTypes = mkOption {
         type = with types; submodule {
           freeformType = types.attrsOf (types.listOf str);

Perhaps renaming defaultMimeTypes to mimeTypeIncludeFiles, and make it a listOf path?

Convert the ${pkgs.mailcap}/etc/nginx/mime.types file to this form?

  mimeTypes = {
    "application/A2L"= [ "a2l" ];
    "application/AML"= [ "aml" ];
    "application/andrew-inset"= [ "ez" ];
    ...

I don't like having both mimeTypes and addMimeTypes, i think the types.nullOr types.path idea makes more sense. But a problem i see we now run into is that

types {
    foo/bar baz;
    foo/qux lux;
}

and

types {
    foo/bar baz;
}
types {
    foo/qux lux;
}

are not equivalent, since the second types block overwrites the first one rather than merge with it. Please correct me if I am wrong about this.

That means the initial version of the PR was more correct, but still a major UX footgun.
So the choice is either to go with the prior approach and add a loud warning, or engineer some mimetype merging tool.

Convert the ${pkgs.mailcap}/etc/nginx/mime.types file to this form?

That would mean essentially vendoring the mailcap mimetypes list to avoid IFD, which puts its maintanance burden on us. (This could be aided with a test to check for equivalence with the one in mailcap.)

What about perhaps a scripted approach? Meaning a script that extracts the content of ${pkgs.mailcap}/etc/nginx/mime.types and joins it with the proposed services.nginx.mimeTypes? As a start I made sed -zE 's/^types\s*\{(.*)\}\s*$/\1/', but one problem with it is that it does not error if it finds no match...

types {
foo/bar baz;
}
types {
foo/qux lux;
}

In this variant, both types are added.

What about perhaps a scripted approach? Meaning a script that extracts the content of ${pkgs.mailcap}/etc/nginx/mime.types and joins it with the proposed services.nginx.mimeTypes? As a start I made sed -zE 's/^types\s*{(.)}\s$/\1/', but one problem with it is that it does not error if it finds no match...

I tried to do something similar here:
#203433

Removed parametr 'addMimeTypes'.

A common use case I see is that one would like to keep the default mime-types, but add one or two additional file types.

Сould try using an variant like this. Tested it, it works.

  commonHttpConfig = ''
    types {
      foo/qux lux;
    }
  '';

I don't know any other simple options for changing mime-types yet.

In this variant, both types are added.

I don't get it. If that's the case, what's wrong with @pbsds's suggestion from #341414 (comment)

I don't get it. If that's the case, what's wrong with @pbsds's suggestion from #341414 (comment)

To reduce the likelihood of conflicts in mime parameters. This is an alternative method of managing mime types, which allows you to specify the minimum required for the site to work.

To reduce the likelihood of conflicts in mime parameters

Well, for that you may set the default mime types to null or not in the proposal, right?

Having this explicit seems less surprising to me.

Well, for that you may set the default mime types to null or not in the proposal, right?

Something like this?
#341414 (comment)

As mentioned above, I'm referring to #341414 (comment).

Update PR.

But I would prefer the previous variant :(