Lighttpd

You're correct that the path should be tested in the configure script. Depending on the distro, NSS and NSPR headers are installed with or without the final version digit. The inconsistency between distros is unfortunate.

That line in configure.ac was added in https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/a46f519eb2e8355221eeeede1b36b7aff0e4a4eb when having lighttpd use the crypto routines from NSS if lighttpd were not compiled with other libraries providing crypto libraries. (See the commit message)

Workaround: you should be able to compile lighttpd --with-nettle so that lighttpd uses Nettle for crypto rather than NSS.

As an aside, NSS upstream development prioritizes client-side, and the server side can be somewhat neglected by comparison. lighttpd does not control this, but please keep that in mind when choosing a TLS library to use with lighttpd. More info about NSS limitations can be found in lighttpd TLS doc

FYI: I left comments in the code at the top of https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/mod_nss.c detailing my struggle with NSS libraries and where its interfaces are lacking for server-side use. lighttpd mod_nss does not support all the features in mod_openssl or other lighttpd TLS modules.

--- a/configure.ac
+++ b/configure.ac
@@ -887,7 +887,11 @@ if test "x$use_nss" = "xyes"; then
       NSS_LIBS="-L$WITH_NSS/lib -lnss3" 
   else
       PKG_CHECK_MODULES([NSS],[nss])
-      CPPFLAGS="$CPPFLAGS -I/usr/include/nspr4" 
+      if test -d "/usr/include/nspr4"; then
+        CPPFLAGS="$CPPFLAGS -I/usr/include/nspr4" 
+      else
+        CPPFLAGS="$CPPFLAGS -I/usr/include/nspr" 
+      fi
   fi
   AC_DEFINE([HAVE_NSS_NSS_H], [1], [nss/nss.h])
   AC_DEFINE([HAVE_NSS3_NSS_H], [1], [nss3/nss.h])

Is there any harm in relying on pkg-config to determine the path?

diff --git a/configure.ac b/configure.ac
index 443e4aff..7a504c5c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -887,7 +887,8 @@ if test "x$use_nss" = "xyes"; then
       NSS_LIBS="-L$WITH_NSS/lib -lnss3" 
   else
       PKG_CHECK_MODULES([NSS],[nss])
-      CPPFLAGS="$CPPFLAGS -I/usr/include/nspr4" 
+      PKG_CHECK_MODULES([NSPR],[nspr])
+      CPPFLAGS="$CPPFLAGS $NSPR_CFLAGS" 
   fi
   AC_DEFINE([HAVE_NSS_NSS_H], [1], [nss/nss.h])
   AC_DEFINE([HAVE_NSS3_NSS_H], [1], [nss3/nss.h])

Maybe. However, due to the nonconformity of nss and nspr and their includes, either patch should get additional testing. lighttpd includes the files (nss/*.h and nspr/*.h) or (nss3/*.h and nspr4/*.h) and NSS and NSPR include without the prefix, expecting their headers to be polluted into the top-level with -I rules when the headers are included with <> rather than ""

If you have tested your patch and that works for you on Gentoo, I'll use that. Again, please see my prior comment about the limitations of NSS when used server-side, and the limitations in lighttpd mod_nss.

I've tested it on Gentoo (/usr/include/nspr) and Fedora Rawhide (/usr/include/nspr4). Both configure and compile correctly for me, though I haven't actually run lighttpd built with it. I'll carve out some time to do that today.

I don't foresee many users setting that USE flag, but I'll make myself a reminder to add your comments as post install info to the ebuild.

I tested the following on Fedora 34. The nspr4 headers are only exposed to the rest of lighttpd if lighttpd is not compiled against any other TLS or crypto library.

--- a/configure.ac
+++ b/configure.ac
@@ -887,7 +887,10 @@ if test "x$use_nss" = "xyes"; then
       NSS_LIBS="-L$WITH_NSS/lib -lnss3" 
   else
       PKG_CHECK_MODULES([NSS],[nss])
-      CPPFLAGS="$CPPFLAGS -I/usr/include/nspr4" 
+      if test "x$CRYPTO_LIB" = "x"; then
+        PKG_CHECK_MODULES([NSPR],[nspr])
+        CPPFLAGS="$CPPFLAGS $NSPR_CFLAGS" 
+      fi
   fi
   AC_DEFINE([HAVE_NSS_NSS_H], [1], [nss/nss.h])
   AC_DEFINE([HAVE_NSS3_NSS_H], [1], [nss3/nss.h])