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
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
fix abort in server.http-parseopts with url-path-2f-decode enabled
(thx stze)
x-ref:
"Security - SIGABRT during GET request handling with url-path-2f-decode enabled"
https://redmine.lighttpd.net/issues/2945
Provide means to encode redirect and rewrite backreference substitutions
%{encb64u:...} encode to base64url characters (no-padding)
%{decb64u:...} decode from base64url characters
Provide means to encode redirect and rewrite backreference substitutions
In addition to $1 and %1, the following modifiers are now supported,
followed by the number for the backreference, e.g. ${esc:1}
${noesc:...} no escaping
${esc:...} escape all non-alphanumeric - . _ ~ incl double-escape %
${escape:...} escape all non-alphanumeric - . _ ~ incl double-escape %
${escnde:...} escape all non-alphanumeric - . _ ~ but no double-esc %
${tolower:...}
${toupper:...}
%{noesc:...}
%{esc:...}
%{escape:...}
%{escnde:...}
%{tolower:...}
%{toupper:...}
Provide means to substitute URI parts without needing a regex match
(and can be preceded by encoding modifier,
e.g. ${tolower:url.authority})
${url.scheme}
${url.authority}
${url.port}
${url.path}
${url.query}
${qsa} appends query string, if not empty
x-ref:
"[PATCH] mod_redirect: Add support for url-encoding backreferences, map %%n->%n, $$n->$n"
https://redmine.lighttpd.net/issues/443
"Need for URL encoding in mod_redirect and possibly mod_rewrite"
https://redmine.lighttpd.net/issues/911
server.http-parseopts = ( ... ) URL normalization options
Note: *not applied* to CONNECT method
Note: In a future release, URL normalization likely enabled by default
(normalize URL, reject control chars, remove . and .. path segments)
To prepare for this change, lighttpd.conf configurations should
explicitly select desired behavior by enabling or disabling:
server.http-parseopts = ( "url-normalize" => "enable", ... )
server.http-parseopts = ( "url-normalize" => "disable" )
x-ref:
"lighttpd ... compares URIs to patterns in the (1) url.redirect and (2) url.rewrite configuration settings before performing URL decoding, which might allow remote attackers to bypass intended access restrictions, and obtain sensitive information or possibly modify data."
https://www.cvedetails.com/cve/CVE-2008-4359/
"Rewrite/redirect rules and URL encoding"
https://redmine.lighttpd.net/issues/1720