I noticed the following regresion after  upgrading to Debian 12 today:

When mod_dirindex is configured to include a header and/or readme into
the directory index (using the dir-listing.show-header or
dir-listing.show-readme options), said header/readme files are not
included reliably into the HTTP response.

Specifically, it looks as if the first request after a pause (or
restart) gets the header/readme included, but any subsequent requests
inside a certain period are rendered without the header/readme.

I tried different stat-cache implementations: "disable", "inotify" and
"simple" - they all could reproduce the same behaviour.

When strace()ing lighttpd, one can clearly see that the README.txt file
(I use dir-listing.show-readme = "README.txt") access pattern changes:

Working case:
newfstatat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...
openat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...

non-working case:
newfstatat(AT_FDCWD, "/data/www/user_dir/HEADER.txt"...

so somehow the file is not opened on the second request.

Some debugging and instrumentation later, it seems that the file is
opened on first access, and then kept open by the stat_cache (even when
"disable" is used, which probably is a separate bug).

However, the mod_dirlisting.c code read()s the file *without rewinding
back after reading it*.  This explains why on first read after open it
succeeds, and subsequent reads then return no data as the read cursor
is already at EOF.

I've so far looked only at debians 1.69-1 sources.  Will check upstream
next and see if there's a fix already available.

I've reported this upstream as I couldn't find the problem fixed even
in git master of today.

upstream bug report is at https://redmine.lighttpd.net/issues/3211

I'm attaching my trivial patch fixing the problem.  Given this is a regression
during distribution upgrade, it would be good to get the package updated with
this fix - before other Debian users fall into the same trap during their upgrade.