Release op1 memory on failure; fixes some theoretical memory leaks (a
failure results in early exit anyway).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3101 152afb58-edef-0310-8abb-c4023f1b3aa9
- raise array size limit from INT_MAX to SSIZE_MAX. INT_MAX already
is way to high to be hit in any sane scenario, but SSIZE_MAX can
*obviously* not be hit due to memory constraints.
- use size_t for array indices instead of int
- use binary search instead of next_power_of_2 hack; document invariants
and check them in debug mode (asserts).
- return the actual insert position instead of something near
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3100 152afb58-edef-0310-8abb-c4023f1b3aa9
- refactor insert into array_find_or_insert; if the element already
exists the caller must resolve the conflict manually:
- array_replace frees the old element
- array_insert_unique calls "insert_dup"
both have no return value anymore
- fix usages of array_replace; they now don't need to delete the old
entry anymore; usage in configparser was probably broken, as it
possibly deleted the old element before calling array_replace
This should fix a lot of the issues reported in "Fortify Open Review
Project - lighttpd 1.4.39" (usually hitting the array limit):
when the array size limit was hit "new" entries leaked instead of
getting added.
On 32-bit INT_MAX entries cannot actually be reached (each entry
requires at least 48 bytes, leading to a total of 96GB memory).
On 64-bit INT_MAX entries would require 224GB memory, so it would be
theoretically possible. But it would need 2^27 reallocations of two
C-arrays of up to 16GB size.
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3098 152afb58-edef-0310-8abb-c4023f1b3aa9
Impact is probably low on most platforms, as it will probably overwrite
one byte of "HASH HA1" which isn't used afterwards anymore.
Reference: Fortify Open Review Project - lighttpd 1.4.39
ID 22708159 - Buffer Overflow: Off-by-One
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3096 152afb58-edef-0310-8abb-c4023f1b3aa9
Reference: Fortify Open Review Project - lighttpd 1.4.39
ID 22708125 - Type Mismatch: Signed to Unsigned
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3095 152afb58-edef-0310-8abb-c4023f1b3aa9
wait for CGI to close stdout, so we read EOF on pipe to end CGI response
remove extra call to waitpid() which will occur after process exits
if it has not already been explicitly closed by CGI (and has not been
inherited by CGI forked children) (If CGI forks, then it should close
its stdout response pipe when response is done, especially if it intends
to perform lengthy post-processing in the background.)
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3091 152afb58-edef-0310-8abb-c4023f1b3aa9
(Thx, anomie, who identified and explained problem in above ticket)
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3089 152afb58-edef-0310-8abb-c4023f1b3aa9
instead of looping over all config blocks for each conditional var that
gets enabled, enable them all and run over them once.
Right now it seems we actually set all variables at once in normal
config handling (SNI only sets a subset); future modifications
might introduce new variables which are activated at a later stage
(physical path related for example).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3083 152afb58-edef-0310-8abb-c4023f1b3aa9
- add new "skip" result to mark conditions that didn't actually get
evaluated to false but just skipped because the preconditions failed.
- add "local_result" for each cache entry to remember whether the
condition itself matched (not including the preconditions).
this can be reused after a cache reset if the condition itself was not
reset, but the preconditions were
- clear result of subtree (children and else-branches) when clearing a
condition cache
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3082 152afb58-edef-0310-8abb-c4023f1b3aa9
The first condition which evaluates true in any if-else... condition
chain short-circuits the chain, and any remaining conditions in the
chain are marked false.
Previous conditions in if-else condition chaining must be evaluatable
(to true or false) -- must not remain in unset (not yet evaluatable)
state -- prior to evaluating later conditions. Since any true
condition short-circuits remaining conditions, all prev conditions
must be false prior to evaluating later conditions.
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3081 152afb58-edef-0310-8abb-c4023f1b3aa9
only use values in reduce actions when the config is still valid
(ctx->ok).
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3080 152afb58-edef-0310-8abb-c4023f1b3aa9
do not propagate sighup if 0 == server.max-workers; reduce impact of
sighup on child processes, such as piped loggers, by not forwarding
sighup signal unless server.max-workers configured
For those configuring server.max-workers, it is recommended that
piped loggers be used to avoid log corruption, and then admins can
avoid sending lighttpd SIGHUP as there is currently no benefit to
doing so with the standard modules (beyond that of log rotation of
non-piped access and error logs).
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3076 152afb58-edef-0310-8abb-c4023f1b3aa9
Flash filesystem JFFS2 does not support mmap PROT_READ MAP_SHARED,
though it does support mmap PROT_READ MAP_PRIVATE
Although MAP_SHARED is preferred, CGI input body is fully collected
prior to handler invoking the CGI, so the temporary file is never
modified after being mapped. Since the request input body is specific
to request and is temporary file, mmap PROT_READ MAP_PRIVATE works fine.
From: Glenn Strauss <gstrauss@gluelogic.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3075 152afb58-edef-0310-8abb-c4023f1b3aa9
Try ssi_vars if ssi_cgi_env does not have a matching var name.
Allow var names to also include digits after the initial letter or underscore.
From: fbrosson <fbrosson@users.noreply.github.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3069 152afb58-edef-0310-8abb-c4023f1b3aa9
- scons searches the dynamic libs to find all dependencies to link
against in the static link:
- now use the system search path (ld --verbose) instead of some
hardcoded list
- remove duplicates from the list (all but the last) to avoid linker
errors
- use custom WhereIsFile function instead of env.WhereIs to find
not-executable files too
- only write 'plugin-static.h' if it actually changes
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3066 152afb58-edef-0310-8abb-c4023f1b3aa9
If the crypt function is available as part of the standard
system library, then HAVE_LIBCRYPT will not be set, but
HAVE_CRYPT or HAVE_CRYPT_R will.
Make server.c test HAVE_CRYPT, HAVE_CRYPT_R and HAVE_LIBCRYPT
to determine the correct value of crypt support.
Signed-off-by: Kyle J. McKay
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3061 152afb58-edef-0310-8abb-c4023f1b3aa9
The FreeBSD version of sendfile is already supported. Starting
with OS X 10.5, Darwin also supports sendfile, but using a
slightly different argument list even though much of the
implementation is likely taken from FreeBSD just like the man
page is.
Add support for darwin's sendfile by introducing a new
network_darwin_sendfile.c file that's just a copy of the
network_freebsd_sendfile.c file except with the arguments
adjusted to compensate for the minor API difference (FreeBSD
has separate in and out byte count arguments whereas Darwin
has a combined in/out byte count argument).
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3060 152afb58-edef-0310-8abb-c4023f1b3aa9
When a sockaddr_un, sockaddr_in or sockaddr_in6 structure
is allocated on the stack or heap, it may contain random
byte values.
The "unused" and "reserved" parts must be zerod otherwise
unexpected failures may occur. The simplest way to do
this and be compatible with various platforms' struct
layouts is just to memset them to 0.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3059 152afb58-edef-0310-8abb-c4023f1b3aa9
Darwin's crypt does not support the '$...' extensions.
Signed-off-by: Kyle J. McKay
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3056 152afb58-edef-0310-8abb-c4023f1b3aa9
Stefan Bühler
Glenn Strauss
fbrosson