quiet more request parse errors unless debug enabled with
debug.log-request-header-on-error = "enable"
x-ref:
"invalid character in URI -> 400 config?"
https://redmine.lighttpd.net/boards/2/topics/9512
more consistent use of shared code config_plugin_value_tobool()
(thx tow-conf)
x-ref:
"The on/off keywords in boolean configuration options is inconsistent, which might be misleading and error-prone."
https://redmine.lighttpd.net/issues/3036
When server.stream-request-body = 0 (the default), the entire request
body is collected before engaging the backend. For backends which
require data framing, this could lead to growth in memory use as large
requests were framed all at once.
Prefer to retain large request bodies in temporary files on disk and
frame in portions as write queue to backend drains below a threshold.
x-ref:
"Memory Growth with PUT and full buffered streams"
https://redmine.lighttpd.net/issues/3033
(bug on master branch)
With lighttpd defaults, including fully buffering request body, and
if request body > 1 MB, then multiple temporary files are used and
might not have open fd in chunkqueue. This would result in failure
to send request body to CGI. (bug commited to master branch 1 month ago)
This alternative approach attempts to work around error:
invalid application of 'sizeof' to incomplete type 'struct kevent'
seen in continuous integration (CI) autoconf build on FreeBSD VM
disable server.graceful-restart-bg on OpenBSD and NetBSD
kqueue is not inherited across fork, and OpenBSD and NetBSD do not
implement rfork() (implemented on FreeBSD and DragonFly)
lighttpd has not implemented rebuilding the kqueues after fork,
so server.graceful-restart-bg is disabled on OpenBSD and NetBSD.
Note: there have always been limitations with lighttpd stat_cache.[ch]
using FAM/gamin on *BSD via kqueue() as lighttpd stat_cache.[ch] only
monitors directories. This kqueue() implementation also only monitors
directories and has limitations.
lighttpd stat_cache.[ch] is notified about additions and removals of
files within a monitored directory but might not be notified of changes
such as timestamps (touch), ownership, or even changes in contents
(e.g. if a file is edited through a hard link)
server.stat-cache-engine = "disable" should be used when files should
not be cached. Full stop. Similarly, "disable" is recommended if files
change frequently. If using server.stat-cache-engine with any engine,
there are caching effects and tradeoffs.
On *BSD and using kqueue() on directories, any change detected clears
the stat_cache of all entries in that directory, since monitoring only
the directory does not indicate which file was added or removed. This
is not efficient for directories containing frequently changed files.
Update: NSS developer explains:
"The way that we currently operate is to tie the session key encryption
to the server public key. Which only works if you have an RSA key
configured"
https://bugzilla.mozilla.org/show_bug.cgi?id=1673254
include wolfssl/options.h crypto lib config
after selecting crypto lib to use
wolfSSL does not prefix its defines with a wolfSSL-specific namespace
(so we would like to avoid unnecessarily polluting preproc namespace)
This commit further isolates wolfSSL after split from mod_openssl.
Cleans up some preprocessor logic that was put in place when using
the wolfSSL compatibility layer for openssl, before creating a
dedicated mod_wolfssl.
workaround fragile code in wolfssl/wolfcrypto/types.h
Including header blows up compile in 32-bit when lighttpd meson build
in OpenWRT on a 32-bit platform generates lighttpd config.h containing
define of SIZEOF_LONG, but not SIZEOF_LONG_LONG, and the wolfssl types.h
flubs and fails to choose an enum value used by a macro that is unused
by most consumers of the wolfssl header.
disabled by default, but can be enabled
(session tickets should be preferred)
applies to mod_openssl, mod_wolfssl, mod_nss
session cache is not currently implemented in mod_mbedtls or mod_gnutls
(not (yet?) an end-user option in the build system)
(If extended to build system, build system should also unset CRYPTO_LIB)
If WITHOUT_LIB_CRYPTO is defined in sys-crypto.h, then non-TLS modules
will have access to MD5() and SHA1() built with lighttpd (algo_md5.[ch]
and algo_sha1.[ch]), but not to other message digest algorithms.
As of this commit, this affects only mod_secdownload with SHA256 digest
and mod_auth* modules using HTTP Digest Auth with digest=SHA-256, which
is not currently well-supported by client browers (besides Opera)
need to build wolfSSL library with --enable-alpn for ALPN
even if already building wolfSSL library with --enable-openssall
(sigh)
ALPN is required by the HTTP/2 specification
crippled functionality if wolfssl library not built --enable-opensslall
* SNI not handled since SNI callbacks are disabled in wolfSSL library
unless the wolfSSL library is built with --enable-openssall
This means that there is only one certificate per listening socket --
no certificate selection based on server name indication (SNI)
and is additionally a violation of the HTTP/2 specification,
which requires SNI.
slightly reduced functionality if wolfssl not built --enable-opensslall
* disable client certificate verification (error out if in lighttpd.conf)
* omit SSL_CIPHER_USEKEYSIZE, SSL_CIPHER_ALGKEYSIZE env vars
(thx avij)
must update the cached copy of global scope config after cycling log.
Although (accesslog_st *) is modified in-place, the log_access_fd member
of (accesslog_st *) is copied into the cache and must be updated after
cycling logs in the global scope.
basic algorithms fail if NSS library has not been init'd (WTH)
lighttpd defers initialization of rand and crypto until first use
to attempt to avoid long, blocking init at startup while waiting
for sufficient system entropy to become available
use http_chunk_append_file_ref() and http_chunk_append_file_ref_range()
reduce resource usage (number of fds open) by reference counting open
fds to files served, and sharing the fd among FILE_CHUNKs in responses
minimize pause during graceful restart for server.max-worker = 0 case
The previous generation continues to accept new connections until the
restarted parent signals that the restarted server is ready to accept
new connections, and so the previous server should gracefully shutdown.
This does not apply in the case of multiple workers.
When there are multiple workers, they receive SIGINT to gracefully shut
down and stop accepting new connections. While the listen sockets are
kept open (and not closed and reopened), there is a small pause while
the parent process restarts before it begins accepting new connections
from the listen backlog.
Note: there is a window during restart during which lighttpd may exit
if it receives certain signals before it sets up signal handlers.
future: might block signals (sigprocmask()) during restart, but if that
is done, then care must be taken to unblock signals in restarted server
as soon as signal handlers are set up and before any other children are
created, e.g. by modules, or else signals must be explicitly unblocked
in children. Also, during command line and config file processing,
signals would be blocked, too, which might not be ideal.
use NSS crypto if no other crypto avail, but NSS crypto is available
"NSS crypto support" is not included in tests/LightyTest.pm:has_crypto()
due to NSS libraries (freebl3) lacking public export for HMAC funcs
wolfSSL_CTX_set_mode() differs from openssl SSL_CTX_set_mode().
wolfSSL_CTX_set_mode() takes a single flag at a time and has
sparse flag support (small number of recognized flags)
return values for sys-crypto-md.h interfaces
While some library implementations do not fail and have no return value,
others might fail on memory allocation or on failure to communicate with
an external or dedicated engine or device, e.g. which might store a
private key.
future: lighttpd callers of sys-crypto-md.h do not currently expect
or check for errors from these digest functions, but should
consider doing so.
provide implementations for conventional digest interfaces
but use the newer openssl digest interfaces under the hood
<rant>
It is baffling that the openssl library -- with *thousands* of public
interfaces -- does not provide these, and suggests that openssl
developers do not frequently write apps which utilize these interfaces.
</rant>
avoid potential double-copy due to not enough space for final '\0'
in http_chunk_append_read_fd_range() if read size is exactly multiple
of 8k and sending chunked response
simple interface to cache open file by extending struct stat_cache_entry
future: should probably create fd cache separate from stat_cache,
perhaps along w/ http-specific fields like etag and content_type
walk chunkqueue up to first FILE_CHUNK (if present)
This may incur memory load misses for pointer chasing, but effectively
preloads part of the chunkqueue, something which used to be a side
effect of a previous (less efficient) version of chunkqueue_length()
which walked the entire chunkqueue (on each and every call). The loads
here make a measurable difference in performance in underlying call to
con->network_write()
(replace existing check which suffered from ToC-ToU race condition)
enhances logic from 2015 commit 593599f1 and avoids repeated fstat()
checks when sending large files
For mmap(), lighttpd catches SIGBUS if file is (externally) truncated
and lighttpd attempts to access bytes in a read-only mapping more than
a memory page boundary following the end of the file.
For sendfile(), lighttpd returns an error if sendfile() reports no error
and that no bytes have been sent after lighttpd attempts to send a
non-zero number of bytes.
server.feature-flags += ("server.graceful-shutdown-timeout" => 10)
After receiving SIGINT or SIGUSR1, lighttpd will gracefully shutdown,
waiting for existing connections to complete. In the case of SIGUSR1,
this wait occurs before restarting lighttpd. The default timeout is
none (unlimited).
When "server.graceful-shutdown-timeout" option is set, it defines the
number of seconds that lighttpd will wait for existing connections to
complete before shutting down the connection.
Sites which expect large uploads or downloads, or those with very slow
clients, might want to set a much longer timeout, e.g 60 seconds
For more immediate graceful restarts, while still allowing existing
connections time to complete, sites should additionally consider
whether or not
server.feature-flags += ("server.graceful-restart-bg" => "enable")
is appropriate and compatible with their lighttpd.conf settings
graceful and (nearly) immediate lighttpd restart option
For *some* configurations, it *may* be safe to background the current
lighttpd server (or workers) to continue processing active requests
and, in parallel, to start up a new lighttpd server with a new
configuration. For other configurations, doing so might not be safe!
Therefore, this option must be explicitly configured to enable:
server.feature-flags += ("server.graceful-restart-bg" => "enable")
server.systemd-socket-activation = "enable"
Along with enabling server.feature-flags "server.graceful-restart-bg",
enabling server.systemd-socket-activation allows transfer of open
listening sockets to the new lighttpd server instance, and occurs
without closing the listening sockets and without destroying the
kernel listen backlog queue on the socket.
Safe configurations may include lighttpd.conf which connect to
standalone backend daemons, e.g. proxying to other servers,
including PHP-FPM backends.
Unsafe configurations include lighttpd.conf which use "bin-path" option
in *.server configs, instructing lighttpd to execute the backends.
Using the graceful-and-immediate-restart option is likely *unsafe* if
the backend daemon expects only one instance of itself to run at a time.
Current implementation of graceful and immediate restart option keeps
the backgrounded lighttpd in the same process group, so that subsequent
SIGINT or SIGTERM will shut down both the new and the backgrounded
servers. (An alternative option (commented out in the code) is to
background and detach from the new lighttpd process.) Regardless,
existing subprocesses, such as CGI, remain in original process group.
As a result, the new lighttpd server may receive SIGCHLD for unknown
processes inherited from the old server, which the new lighttpd server
will reap and discard. The original lighttpd server, now a child, will
be unable to detect exit or reap and report status on those pre-existing
subprocesses.
Graceful restart is triggered in lighttpd by sending lighttpd SIGUSR1.
If lighttpd is configured with workers, then SIGINT (not SIGUSR1) is
sent to the process group, including other processes started by
lighttpd, e.g. CGI. To work well with graceful restart, CGI scripts and
other processes should trap SIGINT (and SIGUSR1 for good measure).
Long-running scripts may want to checkpoint and close, e.g. a CGI script
implementing a long-running websocket connection.
(experimental)
add option to run lua scripts in lighttpd response start hook
allows for response header manipulation
new params provide read-only access:
lighty.env["response.http-status"]
lighty.env["response.body-length"]
lighty.env["response.body"]
allows for content manipulation if the response body is complete
The HTTP response status can be accessed in lua via
lighty.env["response.http-status"] and should be checked, as
appropriate, prior to body manipulation. The value is non-zero
in response start hook (magnet.attract-response-start-to), but is
likely to be 0 in scripts run from other lighttpd hooks earlier in
request processing,
e.g. magnet.attract-raw-url-to or magnet.attract-physical-path-to
Caller should check lighty.env["response.body-length"]
is a smaller and sane amount to read into memory and copy
a second time into lua data structures. The value is lua nil
if the response body is not yet complete (or if it is >= 2GB-1)
Loading the response body (and all mod_magnet lua scripts) are
executed serially (blocking) in lighttpd, so its use is highly
discouraged on large files. The body can be accessed in lua via
lighty.env["response.body"] if the response body is complete.
(recommended config option: server.stream-response-body = 0 (default)
if mod_magnet scripts must process the response body)
Modifying HTTP response status and response body has not changed
and is achieved by setting lua script return value and modifying
the lighty.content lua table.
(note: mod_magnet, mod_setenv, mod_deflate, mod_expire have their
response start hooks run in the order listed in server.modules)
relay 1xx from backend over HTTP/1.1, e.g. 103 Early Hints
(if client is connected using HTTP/1.1)
enabled by default unless disabled in lighttpd.conf with:
server.feature-flags += ( "server.h1-discard-backend-1xx" = "enable" )
Warning: backends which send 103 Early Hints should check User-Agent
before doing so since naive clients might not handle unexpected 1xx.
Some clients may take the 1xx response as the final response, expecting
only one response. Some clients might not properly handle 100 Continue
if the client did not send Expect: 100-continue with the request.
https://tools.ietf.org/html/rfc8297#section-3 Security Considerations
x-ref:
An HTTP Status Code for Indicating Hints (103 Early Hints)
https://tools.ietf.org/html/rfc8297
relay 1xx from backend over HTTP/2, e.g. 103 Early Hints
(if client is connected using HTTP/2)
enabled by default unless disabled in lighttpd.conf with:
server.feature-flags += ( "server.h2-discard-backend-1xx" = "enable" )
Warning: backends which send 103 Early Hints should check User-Agent
before doing so since naive clients might not handle unexpected 1xx.
Some clients may take the 1xx response as the final response, expecting
only one response. Some clients might not properly handle 100 Continue
if the client did not send Expect: 100-continue with the request.
https://tools.ietf.org/html/rfc8297#section-3 Security Considerations
x-ref:
An HTTP Status Code for Indicating Hints (103 Early Hints)
https://tools.ietf.org/html/rfc8297
support multiple 1xx intermediate responses from backends
Currently, all 1xx responses from backends are discarded.
In the future, these 1xx responses may be forwarded to the client
(when lighttpd also configured server.stream-response-body = 1 or = 2)