short-circuit path to clear con->request.headers if entire size of
all request headers is <= BUFFER_MAX_REUSE_SIZE
clear (reset) data_string key and value upon reuse
even 2 billion is way larger than even extreme operating values
expected for the members in base.h
include some structs directly in struct server, rather than by ptr
mark funcs cold if seldom used or used only at startup config processing
mark most data_config_* funcs cold
data_*_copy()
data_*_insert_dup()
data_*_print()
data_*_reset()
array_reset()
mark array_get_index() as hot, rewrite to be pure and return sorted pos
mark routines as pure, as appropriate
mark routines as cold if used only at startup for config processing
mark params const, as appropriate
array_get_buf_ptr() for modifiable value buffer after insert into array
uint32_t used and size members instead of size_t
remove a->unique_ndx member; simply add to end of array for value lists
remove du->is_index_key member; simply check buffer_is_empty(du->key)
array_insert_key_value() used to be a hint that lookup could be skipped,
but the state from array_get_index() is now saved and reused internally,
so the distinction is no longer needed. Use array_set_key_value().
inline connection_read_header() into connection_handle_read_state()
(The large stack usage prevents the compiler from inlining the routine,
but if we enter connection_handle_read_state(), then we are going to
be running connection_read_header(), so put them together)
In some circumstances, if the character on the heap prior to the
beginning of the request is '\r', then it would be overwritten with '\0'
With default compiler flags, this does not appear to occur in practice
and we therefore believe it to be a low-probability vulnerability.
(thx Antonio Morales)
This issue was discovered and reported by GSL team member @
<https://github.com/antonio-morales>antonio-morales
<https://github.com/antonio-morales> (Antonio Morales)
On some architectures, accept4() might result in EPERM depending
on Linux kernel and/or glibc support for accept4()
(thx alex-che)
x-ref:
"accept4 returns EPERM instead of ENOSYS on some platforms"
https://redmine.lighttpd.net/issues/2998
normalize %2b or %2B in query string to %2B (uppercase hex),
and not to '+'
(thx int-e)
x-ref:
"url-normalize-required expands %2B in query strings"
https://redmine.lighttpd.net/issues/2999
reject requests with both Transfer-Encoding and Content-Length
as recommended in RFC 7230 Section 3.3.3.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept Transfer-Encoding and Content-Length in the same request,
and will ignore (and remove) Content-Length before passing to backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
3.3.3. Message Body Length
[...]
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream.
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
reject whitespace following request header field-name and before colon
Such whitespace is forbidden in RFC 7230 Section 3.2.4.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept (and re-format) such field-names before passing to any backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
(thx fedormixalich)
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
raw