reuse cache lookup in common case of serving a static file
rather than repeating the stat_cache_entry lookup
(which is more work than memcmp() to re-check stat_cache_entry match)
HTTP/2 requires that TLS protocol >= TLSv1.2
HTTP/2 requires that TLS record compression be disabled
HTTP/2 requires that TLSv1.2 renegotiation be disabled
HTTP/2 requires that TLS SNI extension be presented with ALPN h2
(not enforced;
SNI omitted by client when connecting to IP instead of to name)
RFC 7540 9.2 Use of TLS Features
"Implementations are encouraged to provide defaults that comply,
but it is recognized that deployments are ultimately responsible
for compliance."
If TLS record compression or renegotiation are for some reason required
(which is strongly discouraged), then disable HTTP/2 in lighttpd with
server.feature-flags = ("server.h2proto" => "disable")
slurp password/digest file into memory and then clear after use
(avoid stdio, which buffers by default and does not wipe those buffers)
password/digest files are not expected to be very large
e.g. a password file with 1000 entries is expected to be < 64k
If files are larger, mod_authn_dbi or other mod_authn_* is recommended
HTTP/1.1 dictates that Cache-Control overrides Expires if both present.
Therefore, send only Cache-Control to HTTP/1.1 requests. This means
that if an intermediary upgraded the request to HTTP/1.1, and the actual
client sent HTTP/1.0, then the actual client might not understand
Cache-Control when it may have understood Expires. RFC 2616 HTTP/1.1
was released June 1999, almost 22 years ago (as this comment is written)
If a client today is sending HTTP/1.0, chances are the client does not
cache. Avoid the overhead of formatting time for Expires to send both
Cache-Control and Expires when the majority of clients are HTTP/1.1 or
HTTP/2 (or later).
(thx oldium)
improve handling of HTTP/2 DATA frames received
a short time after sending response
x-ref:
"POST request DATA part for non-existing URI closes HTTP/2 connection prematurely"
https://redmine.lighttpd.net/issues/3078
rename to reflect use for verifying client certificate
(old names are still accepted, but are discouraged)
ssl.ca-file -> ssl.verifyclient.ca-file
ssl.ca-dn-file -> ssl.verifyclient.ca-dn-file
ssl.ca-crl-file -> ssl.verifyclient.ca-crl-file
send HTTP/1.0 request to backend if no Host header sent with request
(If Host header is present with an HTTP/1.0 request from client, then
lighttpd can still make an HTTP/1.1 request to backends)
dir-listing.cache = ( "path" => "..." # path to cache root
"max-age" => 15 ) # max age (default 15 sec)
Simple cache of directory listing. Generating directory listing
on large directives can be expensive. Cache listing for reuse.
This option is for convenience to improve the performance of
directory listings on busy servers, and requires very little
effort for web server admin to enable.
For even better performance on busy servers, the directory listings
could be (externally) generated into index.html files, and mod_indexfile
could be used instead of mod_dirlisting. When directories are modified,
an external trigger could regenerate index.html.
parse (optional) query string in javascript to affect initial list sort
(which is also done in javascript)
This change allows the server-generated page to be cachable,
as the response is now independent of the query string.
set upper limit of 1/16 max_conns for parallel dirlist
(per lighttpd worker)
or else set 503 Service Unavailable with Retry-After: 2
attempt to avoid "livelock" scenarios or starvation of other requests
1/16 max_conns (default 85) is still a high arbitrary limit;
and limit applies only to directories larger than DIRLIST_BATCH-2
(DIRLIST_BATCH is currently 32)
read dir in pieces, allowing server to do other work between reads
(avoid potentially blocking other requests for long periods of time
while reading a large directory)
Glenn Strauss