Lighttpd

To be clear: lighttpd plans to continue to support both --with-pcre2 and --with-pcre options. However, upstream pcre development has made it clear that only pcre2 will be developed and maintained moving forwards.

You're welcome to continue building lighttpd using --with-pcre.

To use --with-pcre2, please try the following in your lighttpd.conf:
server.feature-flags += ("server.pcre_jit" => "disable")

You might alternatively look into upgrade pcre2 on your system to see if that resolves the issue for you.

Please report back.

Also, if you can, please provide more details about the tests failing. lighttpd ignores the "bad JIT option" since it should (possibly) affect only performance, and should function properly with or without the jit enabled.

Thanks so much, both for the quick reply and for the news that I've not done something daft. Thanks, too, for making clear that it's an upstream impetus regarding pcre2.

I can confirm that

server.feature-flags += ("server.pcre_jit" => "disable")

The version of pcre2 in OpenSUSE 15.3 is 10.31-3.3.1. I see that the current version is 10.39. I'm reluctant to start upgrading so reduce the likelihood of dependency hell on a number of systems, and anyway, openSUSE 15.4 isn't too far away.

As a matter of interest, is there value in running --with-pcre2 (along with the feature-flag) as opposed to running a version compiled --with-pcre?

Re more details, the problem I have is not know what is causing the failure. The first (pdf reference) error is in the main lighttpd.conf file. But here is the sanitised vhost from which most errors are generated:

##VirtualHost homenet (old intranet)
## Only accessible from home network

$HTTP["host"] =~ "xxxx.xxxx.xx.xx" {

$HTTP["remoteip"] !~ "192.168.18\.|192.168.19\." {
}
    server.document-root = "/srv/www/htdocs/assyntlives" 
    accesslog.filename = "/var/log/lighttpd/homenet-access.log" 

############Omeka####
url.rewrite-once = (
##admin pages
  "^/omeka/admin([^.?]*)\?(.*)$" => "/omeka/admin/index.php?q=$1&$2",
  "^/omeka/admin([^.?]*)$" => "/omeka/admin/index.php?q=$1",
##Main pages
  "^/omeka/([^.?]*)\?(.*)$" => "/omeka/index.php?q=$1&$2",
  "^/omeka/([^.?]*)$" => "/omeka/index.php?q=$1",
)
#########################################

$HTTP["url"] =~ "^/test($|/)" { server.dir-listing = "enable" }
}

And I think you've answered my previous question, suggesting that the only difference might be performance.

You probably won't notice any performance difference for most simple regexes.

I just took a look in the PCRE2 code and if your distribution did not build the pcre2 libraries with SUPPORT_JIT defined, then "bad JIT option" is returned to any attempt to jit. I have added a patch to lighttpd for the next lighttpd release which will not issue trace for PCRE2_ERROR_JIT_BADOPTION.

FYI: some regex fun: one lighttpd url.rewrite-once regex to replace 4 of yours:
url.rewrite-once = ("^/omeka(/admin)?([^?]*)" => "/omeka$1/index.php?q=$2${qsa}") (I think you want [^?] for "not '?'" rather than [^.?] for "not '.' or '?'")
Depending on how Omeka handles things, you might want to use url.rewrite-if-not-file instead of url.rewrite-once to let lighttpd serve static files instead of index.php.

$HTTP["remoteip"] !~ "192.168.18\.|192.168.19\." is more efficiently written in CIDR notation: $HTTP["remoteip"] != "192.168.18.0/23"

Not using a regex, or using fewer regexes, is often (marginally) faster than using regexes, with or without jit.

$HTTP["url"] =~ "^/test($|/)" { server.dir-listing = "enable" }
server.dir-listing is an old name for dir-listing.activate, and mod_dirlisting applies only to directories ending in '/', so this is sufficient:
$HTTP["url"] =~ "^/test/" { dir-listing.activate = "enable" }

That's just brilliant. Very grateful for the response to the issue, and the patch for the next version.

And thanks for the extra mile regarding the omeka incantations. I'm not surprised my hacks could be improved, but this is very timely, as the entries are in my development system, while I need to put an omeka instance under lighttpd live in the next few weeks.

Thanks again

Very best from a breezy north west Scotland.

Stevan