srv->lim_conns tracks remaining conns until limit is reached,
replacing (srv->max_conns - srv->conns.used)
srv->srvconf.max_conns is now updated at startup, so
srv->srvconf.max_conns serves as srv->max_conns
keep conns_pool of struct connection separate from conns list
and allocate conns list to srv->srvconf.max_conns size at startup
x-ref:
"Memory fragmentation with HTTP/2 enabled"
https://redmine.lighttpd.net/issues/3084
return HANDLER_FINISHED from http_response_read() if response finished,
whether due to reading EOF (prior behavior), or if Content-Length was
provided and we have finished reading Content-Length, or if a module
sets r->resp_body_finished for any other reason. This may save an
unnecessary poll() and read() to receive EOF when Content-Length has
already been read.
manage r->resp_body_scratchpad in new funcs
http_response_append_buffer()
http_response_append_mem()
rather than
http_chunk_decode_append_buffer()
http_chunk_decode_append_mem()
which now only decode chunked encoding, more apropos for the func names
mod_compress was removed in lighttpd 1.4.56, subsumed by mod_deflate.
distros may package mod_deflate separately from the lighttpd package.
However, existing configurations may reference mod_compress.
lighttpd maps the reference from mod_compress to mod_deflate,
but after a system is upgraded to lighttpd 1.4.56 or later,
mod_compress may have been removed, and mod_deflate -- which
might be a separate package -- might not be installed.
lighttpd will still issue error trace about the missing mod_deflate
modules, as well as about the unrecognized configuration directives
(compress.* or deflate.*), but this will no longer be a fatal error.
If mod_sockproxy -- or other connection-level handler -- has been set
on the request prior to mod_openssl processing TLS Client Hello, then
failure to match ALPN protocol is no longer treated as a TLS connection
setup error.
x-ref:
"sockproxy: Do not validate ALPN protocols"
https://redmine.lighttpd.net/issues/3081
Most OS platforms have already provided solutions to
Y2038 32-bit signed time_t 5 - 10 years ago (or more!)
Notable exceptions are Linux i686 and FreeBSD i386.
Since 32-bit systems tend to be embedded systems,
and since many distros take years to pick up new software,
this commit aims to provide Y2038 mitigations for lighttpd
running on 32-bit systems with Y2038-unsafe 32-bit signed time_t
* Y2038: lighttpd 1.4.60 and later report Y2038 safety
$ lighttpd -V
+ Y2038 support # Y2038-SAFE
$ lighttpd -V
- Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE
* Y2038: general platform info
* Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t
- all major 64-bit platforms (known to this author) use 64-bit time_t
* Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t
- Linux x32 ABI (different from i686)
- FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386
- NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures
- OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures
- Microsoft Windows XP and Visual Studio 2005 (? unsure ?)
Another reference suggests Visual Studio 2015 defaults to 64-bit time_t
- MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps
* Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t
- e.g. OpenVMS (unknown if lighttpd builds on this platform)
* Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t
- Linux 32-bit (including i686)
- glibc 32-bit library support not yet available for 64-bit time_t
- https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
- Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t
https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/
- https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
"Note: at this point, 64-bit time support in dual-time
configurations is work-in-progress, so for these
configurations, the public API only makes the 32-bit time
support available. In a later change, the public API will
allow user code to choose the time size for a given
compilation unit."
- compiling with -D_TIME_BITS=64 currently has no effect
- glibc recent (Jul 2021) mailing list discussion
- https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/
- FreeBSD i386
- DragonFlyBSD 32-bit
* Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t)
* lighttpd prefers system monotonic clock instead of realtime clock
in places where realtime clock is not required
* lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT
* (lighttpd presumes that lighttpd will not encounter dates before 1970
during normal operation.)
* lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t
to convert negative timestamps for comparisions with 64-bit timestamps
(treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT)
* lighttpd provides unix_time64_t (int64_t) and
* lighttpd provides struct unix_timespec64 (unix_timespec64_t)
(struct timespec equivalent using unix_time64_t tv_sec member)
* lighttpd provides gmtime64_r() and localtime64_r() wrappers
for platforms 32-bit platforms using 32-bit time_t and
lighttpd temporarily shifts the year in order to use
gmtime_r() and localtime_r() (or gmtime() and localtime())
from standard libraries, before readjusting year and passing
struct tm to formatting functions such as strftime()
* lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to
unsigned 32-bit and then to unix_time64_t
* Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT
on 32-bit platforms using 32-bit signed time_t, underlying libraries and
underlying filesystems might not behave properly after 32-bit signed time_t
overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work
properly using negative time_t values, then lighttpd likely will not work
properly on that system.
* Other references and blogs
- https://en.wikipedia.org/wiki/Year_2038_problem
- https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs
- http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
mechanism to define per-encoder params
parsed into structured data at startup
compression level is the initial target
deflate.params is a better solution to the deflate.compression-level,
which is a single range 1-9 that is overload and applied to all encoders
without any scaling, even though encoders might have different scales.
x-ref:
"ModDeflate questions (possibly some feature requests too)"
https://redmine.lighttpd.net/boards/2/topics/9786
map deflate.compression-level to ZSTD_c_strategy as the current
enum for ZSTD_strategy is in the range 1 .. 9, which matches the
gzip compression level 1 .. 9 range
x-ref:
"ModDeflate questions (possibly some feature requests too)"
https://redmine.lighttpd.net/boards/2/topics/9786
use deflate.allowed-encodings ordering as server preference list
when choosing an encoding from list in client request Accept header
x-ref:
"ModDeflate questions (possibly some feature requests too)"
https://redmine.lighttpd.net/boards/2/topics/9786
- http_method_buf() returns (const buffer *)
- comment out unused get_http_status_name()
- inline func for http_append_method()
config processing requires a persistent buffer for method on the
off-chance that the config performed a capturing regex match in
$HTTP["method"] condition and used it later (e.g. in mod_rewrite)
(Prior behavior using r->tmp_buf was undefined in this case)
parse $HTTP["remote-ip"] CIDR mask into structured data at startup
note: adds buffer_move() to configparser.y to reduce memory copying
for all config values, and is required for remote-ip to preserve the
structured data added after the config value string. (Alternatively,
could have normalized the remote-ip value after copying into dc->string)
reorder some code for better asm
proxy_set_Forwarded() sets multiple request headers, and does so prior
to walking all request headers to create request to backend. This is
done so that specific already-existing request headers from client are
overwritten (intentionally) in proxy_set_Forwarded().
Expect header is handled, but not expected since client-sent Expect
header is handled (and unset) in connection_handle_read_post_state()
