h2: avoid sending tiny DATA frames when h2 window is tiny
and a larger amount of data is pending to be sent;
wait for slightly larger window to be available
note: must temporarily disable this when running h2spec since some
h2spec tests expect 1-byte DATA frame, not a deferred response
Note this may slow down uploads due to delay in sending WINDOW_UPDATE
smaller than the default max frame size (16384), but as a trade-off
this aims to reduce degenerative behavior from clients sending an
increasing number of tiny DATA frames. The default 65535 value for
SETTINGS_INITIAL_WINDOW_SIZE (which lighttpd immediately increases to
65536) is larger than 16384, so deferring small updates should not
exhaust the window (from lighttpd's perspective).
x-ref:
"Slow upload / Increase CPU/Memory usage with HTTP/2 enabled"
https://redmine.lighttpd.net/issues/3089
"libnghttp2 degenerative behavior possible when HTTP/2 window size exhausted"
https://github.com/nghttp2/nghttp2/issues/1722
Increase stream window size to 64k (from default 64k-1)
Increase session window size to 256k (from default 64k-1)
(multiple of SETTINGS_MAX_FRAME_SIZE (default 16k))
(rely on TCP window scaling and TCP congestion control
to manage client sending too much data)
Window size as multiple of SETTINGS_MAX_FRAME_SIZE (default 16k) may be
friendlier to client buffer management and more efficient for uploading.
Window sizes are not increased to arbitrarily large numbers as the
HTTP/2 flow control may be useful to help simplistic/naive clients
avoid symptoms of buffer bloat.
Bandwidth delay product on high bandwidth, high latency links may be
large, so increasing window sizes may increase performance. However,
lighttpd code does not check actual per-connection RTT or kernel
socket buffer sizes. 256k chosen as session window size, and 192k as
stream window size.
Above changes avoid degenerative behavior from the widely deployed
libnghttp2 which may devolve to sending 1 byte at a time in some cases.
https://redmine.lighttpd.net/issues/3089
x-ref:
"Slow upload / Increase CPU/Memory usage with HTTP/2 enabled"
https://redmine.lighttpd.net/issues/3089
Delivering HTTP/2 upload speed improvements
https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
encapsulate accounting calculations in
http_request_stats_bytes_in()
http_request_stats_bytes_out()
more accurate accounting for HTTP/1.1 bytes_in on keep-alive requests
(affects case where client pipelines HTTP/1.1 requests)
remove con->bytes_read and con->bytes_written
(no longer needed since request_st was split from connection struct
and request bytes_read_ckpt and bytes_written_ckpt are maintained
for HTTP/1.x bytes_in and bytes_out accounting. Also, further back,
chunkqueue internal accounting was simplified to maintain bytes_in
and bytes_out to always match chunkqueue length)
send HTTP/2 SETTINGS_NO_RFC7540_PRIORITIES=1 with server connection
preface
RFC9218 Extensible Prioritization Scheme for HTTP
2.1 Disabling RFC 7540 Priorities
If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in
the first SETTINGS frame.
RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)
6.5.3. Settings Synchronization
Unsupported parameters MUST be ignored.
x-ref:
https://datatracker.ietf.org/doc/html/rfc9218https://datatracker.ietf.org/doc/html/rfc7540
Add support for WebSockets over HTTP/2 to lighttpd core and to
mod_cgi w/ config: cgi.upgrade = "enable"
mod_proxy w/ config: proxy.header += ("upgrade" => "enable")
mod_wstunnel
HTTP/2 CONNECT extension defined in RFC8441 is translated to HTTP/1.1
'Upgrade: websocket' requests to mod_cgi or mod_proxy, and is handled
directly in mod_wstunnel.
x-ref:
WebSockets over HTTP/2
https://redmine.lighttpd.net/issues/3151
Bootstrapping WebSockets with HTTP/2
https://datatracker.ietf.org/doc/html/rfc8441
save config regex captures separately only if used by url.redirect
or url.rewrite replacement directives within the condition
(or for conditions containing directives from any other module
which calls config_capture() for its directives during init)
keep pointer to match data (cond_match_t *) in r->cond_match[]
rather than cond_match_t to reduce data copying in h2_init_stream().
h2_init_stream() copies the results for already-evaluated conditions
to avoid re-evaluating connection-level conditions for each and every
stream. When conditions are reset, then the pointer in r->cond_match[]
is updated when the condition is re-evaluated. (This all assumes that
HTTP/2 connection-level conditions are not unset or re-evaluated once
HTTP/2 streams begin.)
Existing behavior: mod_proxy *does not* forward Upgrade header
unless explicitly enabled in lighttpd.conf (default: not enabled)
(proxy.header += ("upgrade" => "enable"))
mod_cgi previously used to forward Upgrade request header, but would
remove Upgrade response header if cgi.upgrade was not explicitly enabled
(cgi.upgrade = "enable")
This patch thwarts h2c smuggling when lighttpd.conf has also been
explicitly configured to pass "Upgrade" request header
x-ref:
"h2c Smuggling: Request Smuggling Via HTTP/2 Cleartext (h2c)"
https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c
fix HTTP/2 upload > 64k with server.max-request-size > 0
(regression present only in lighttpd 1.4.60)
(thx SM)
x-ref:
"File upload is broken after upgrade from 1.4.59 to 1.4.60"
https://redmine.lighttpd.net/issues/3108
(detect if client erroneously reuses stream id for a different request)
x-ref:
"Chrome gives random net::ERR_HTTP2_PROTOCOL_ERROR"
https://redmine.lighttpd.net/issues/3102
refuse excess streams only if would block DATA frames for active streams
(for excess streams received on initial connect, prior to receiving
SETTINGS ACK from client)
(thx flynn)
x-ref:
"Random TLS errors on established connections"
https://redmine.lighttpd.net/issues/3100
"Chrome 92, HTTP/2, fcgi, mutiple puts no response"
https://redmine.lighttpd.net/issues/3093
refuse excess h2 streams up to stream id 199 within 1-2 seconds of
establishing connection. This attempts to more gracefully handle
excessively agressive browsers sending too many new requests *before*
processing the initial SETTINGS frame sent by the server.
lighttpd HTTP/2 support limits SETTINGS_MAX_CONCURRENT_STREAMS to 8
and communicates this in the initial SETTINGS sent by the server.
x-ref:
"Chrome 92, HTTP/2, fcgi, mutiple puts no response"
https://redmine.lighttpd.net/issues/3093
"POST request DATA part for non-existing URI closes HTTP/2 connection prematurely"
https://redmine.lighttpd.net/issues/3078
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/
This commit is a large set of code changes and results in removal of
hundreds, perhaps thousands, of CPU instructions, a portion of which
are on hot code paths.
Most (buffer *) used by lighttpd are not NULL, especially since buffers
were inlined into numerous larger structs such as request_st and chunk.
In the small number of instances where that is not the case, a NULL
check is often performed earlier in a function where that buffer is
later used with a buffer_* func. In the handful of cases that remained,
a NULL check was added, e.g. with r->http_host and r->conf.server_tag.
- check for empty strings at config time and set value to NULL if blank
string will be ignored at runtime; at runtime, simple pointer check
for NULL can be used to check for a value that has been set and is not
blank ("")
- use buffer_is_blank() instead of buffer_string_is_empty(),
and use buffer_is_unset() instead of buffer_is_empty(),
where buffer is known not to be NULL so that NULL check can be skipped
- use buffer_clen() instead of buffer_string_length() when buffer is
known not to be NULL (to avoid NULL check at runtime)
- use buffer_truncate() instead of buffer_string_set_length() to
truncate string, and use buffer_extend() to extend
Examples where buffer known not to be NULL:
- cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL
(though we might set it to NULL if buffer_is_blank(cpv->v.b))
- address of buffer is arg (&foo)
(compiler optimizer detects this in most, but not all, cases)
- buffer is checked for NULL earlier in func
- buffer is accessed in same scope without a NULL check (e.g. b->ptr)
internal behavior change:
callers must not pass a NULL buffer to some funcs.
- buffer_init_buffer() requires non-null args
- buffer_copy_buffer() requires non-null args
- buffer_append_string_buffer() requires non-null args
- buffer_string_space() requires non-null arg
improve HTTP/2 behavior when server.max-request-size reached
accept slightly more data than max-request-size if END_STREAM flag recvd
reduce rwin so that client may exceed server.max-request-size, but not
by much. (client might ignore and might send a firehose of data anyway)
accept up to 64k more data to potentially sink data that was in-flight
beyond the rwin, in order to allow server to send 413 Payload Too Large
before resetting the stream.
(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
Note: monotonic time does not change while VM is suspended
Continue to use real time where required by HTTP protocol, for logging
and for other user-visible instances, such as mod_status, as well as for
external databases and caches.
cast high uint8_t byte to uint32_t before bit shifting << 24 to avoid
(pedantic) undefined behavior of uint8_t byte with high bit set when
it is promoted to int and then bit-shifted left 24 bytes. The high bit
gets shifted into the sign-bit, which is technically undefined behavior
in C, but is defined behavior in C++.
x-ref:
"pedantic warning from -fsanitize=undefined"
https://redmine.lighttpd.net/issues/3067
