re-patch mod_openssl config within the request so that per-request
settings can be applied, such as activating client cert verification
for specific URL paths.
(This can be used in conjunction with auth.backend = "extern"
to require auth to occur)
"SSL : authenticate only clients for a particular URL"
Set auth.extern-authn = "enable" to check REMOTE_USER (if set) against
require rules, and proceed if allowed. If REMOTE_USER is not present,
or the require rules do not match, then check configured auth scheme.
REMOTE_USER might be set by another module, e.g. mod_openssl client cert
verification and REMOTE_USER configured with ssl.verifyclient.username)
"[mod_auth] allow SSL clientcert authenticated users to bypass AUTH"
handle_request_env (called on demand by handlers to populate env)
handle_connection_shut_wr (was handle_connection_close)
handle_connection_close (now occurs at socket close())
The (misnamed) connection_reset hook is always called after a request,
whether request completes or is aborted, and whether keep-alive or not,
so no needed to repeat the same function in the handle_connection_close
new directive ssl.read-ahead = "enable"/"disable" to control
SSL_CTX_set_read_ahead(). Default "enable". The "disable" setting
is intended for use on low memory systems with a slow CPU which is
unable to keep up with decryption of large request bodies.
"larger memory usage for file uploads via SSL on embedded system"
Loosen local redirect handling in mod_cgi to skip handling as local
redirect if the Location matches con->uri.path, since if the request
is intended to redirect back to the same CGI using the same request
method, path info, and query string, the CGI would logically just
return the final intended response. Loosening this handling avoids a
problem with applications (potentially) accessible through multiple
gateways, where the application is not aware of this specific handling
of Location in the Common Gateway Interface (CGI/1.1), the application
sends abs-path in the Location response header instead of absoluteURI,
and the application expects the client to receive this Location response
header instead of the server to process as a CGI local redirect.
One example of such an application is LuCI,
which sends Set-Cookie with Location: /abs-path
(Note that this loose check for matching con->uri.path is not perfect
and might not match if the CGI returned a path with a different case
and the server is on a case-insensitive filesystem, or if the path
returned by the CGI is rewritten elsewhere to a different con->uri.path
before getting to mod_cgi.)
RFC3875 CGI 1.1 specification section 6.2.2 Local Redirect Response
"CGI local-redir handling conflicts with LuCI redirect w/ Set-Cookie"
"CGI local redirect not implemented correctly"
silence coverity warning
openssl 1.1.0 makes SSL_OP_NO_SSLv2 flag a no-op, leading to
logically dead code when used with openssl 1.1.0. However, the code
is still valid with earlier openssl versions, and so must be preserved.
This change should fix an issue with lighttpd on Debian kfreebsd-* arch
(kfreebsd-amd64 and kfreebsd-i386)
.libs/mod_cgi.o: In function `cgi_create_env':
./src/mod_cgi.c:1103: warning: pipe2 is not implemented and will always fail
lighttpd is single-threaded so there is no race with pipe()
and then fcntl() F_SETFD FD_CLOEXEC on the pair of pipe fds.
Using pipe2() where available is still slightly more efficient
by eliding the syscalls to set FD_CLOEXEC.
Lack of pipe2() on relic Unix as well as missing on Mac OSX is likely
one reason why threaded web servers such as nginx choose not to support
CGI except via an external service to the process. Without pipe2(),
race conditions exist and it is not safe for a threaded server to use
pipe() and fork() when the server also does not want to potentially leak
open file descriptors to various unrelated CGI scripts.
issue warning at startup, instead of fatal error, if SHA used in
secdownload.algorithm = "..." but mod_secdownload was built without
SSL crypto. When lighttpd is built without openssl, this allows most
tests/* to be run and pass, except the ones in tests/mod-secdownload.t
which use "hmac-sha1" or "hmac-sha256".
(alternatively, could have made, used isolated tests/secdownload.conf)
attempt to route requests to same backends based on requestor (client)
IP address and target host and port of request.
"Source IP sticky load balancing patch"
support Transfer-Encoding: chunked request body in conjunction with
server.stream-request-body = 0
dynamic handlers will still return 411 Length Required if
server.stream-request-body = 1 or 2 (!= 0)
since CGI-like env requires CONTENT_LENGTH be set
(and mod_proxy currently sends HTTP/1.0 requests to backends,
and Content-Length recommended for robust interaction with backend)
"request: support Chunked Transfer Coding for HTTP PUT"
EXPERIMENTAL: basic recursive SSI <!--#include virtual="..." -->
Marked experimental since behavior may change in future.
Prior behavior was simpler and treated them all as files included as-is.
New behavior treats all #include virtual="..." targets as SSI files.
In the future, this may change to be a full recursive subrequest and the
virtual path may be treated as a new subrequest and might be something
other than SSI (e.g. might be CGI). This has not been implemented.
Current behavior processes <!--#include virtual="..." --> as static file
Enable new behavior by setting ssi.recursion-max to value other than 0.
ssi.recursion-max = X to set maximum recusion depth
"add recursion to the SSI #include directive"
defer li_rand_init() until first use of li_rand_pseudo_bytes()
li_rand_init() is now deferred until first use so that installations
that do not use modules which use these routines do need to potentially
block at startup. Current use by core lighttpd modules is in mod_auth
HTTP Digest auth and in mod_usertrack. Deferring collection of random
data until first use may allow sufficient entropy to be collected by
kernel before first use, helping reduce or avoid situations in
low-entropy-generating embedded devices which might otherwise block
lighttpd for minutes at device startup. Further discussion in