create API in chunk.[ch] for writing a chunk to an fd
(pull similar code from mod_cgi and mod_webdav)
This new API is intended for use on request body input, which is
written to size-limited temporary files controlled by lighttpd and
written to files or pipes.
(network_backend_write() is for writing chunkqueues to sockets)
FreeBSD provides an API similar to Linux copy_file_range()
but uses off_t instead of loff_t in the syscall.
off_t is equivalent to off64_t when lighttpd is built with LFS
(and lighttpd is built with LFS enabled by default)
replace /* fall through */ comment with __attribute_fallthrough__ macro
Note: not adding attribute to code with external origins:
xxhash.h (algo_xxhash.h)
ls-hpack/lshpack.c
so to avoid warnings, may need to compile with -Wno-implicit-fallthrough
more consistent use of shared code config_plugin_value_tobool()
(thx tow-conf)
x-ref:
"The on/off keywords in boolean configuration options is inconsistent, which might be misleading and error-prone."
https://redmine.lighttpd.net/issues/3036
r->con->reqbody_read() replaces connection_handle_read_post_state()
future: might provide different callbacks for request body with
Content-Length versus request body sent via Transfer-Encoding: chunked
fix fallback if linkat() fails
check at startup if /proc/self/fd is present on systems with O_TMPFILE
(containers might not mount /proc)
x-ref:
"mod_webdav - PUT files with < 64kb Content-Length reults in zero length file"
https://redmine.lighttpd.net/boards/2/topics/9273
fix theoretical NULL dereference identified by Coverity Scan
possible for PROPFIND with specific atypical choices in lighttpd.conf:
- possible for getcontenttype if no content type matches resource
and no default type configured in lighttpd.conf
- possible for getetag if etag disabled in lighttpd.conf
webdav.opts = ("unsafe-propfind-follow-symlink" => "enable")
This option is unsafe and unsupported. This option enables non-standard
behavior. If it works for you, great. If it does not work for you,
then too bad.
WebDAV resource and collection concepts do not have an equivalence
to unix symlinks. If "unsafe-propfind-follow-symlink" is "enable",
then lighttpd mod_webdav PROPFIND handling will follow symlinks
if and only if webdav.is_readonly = "enable" is also set.
Allowing symlinks is unsafe in the general case. Using WebDAV methods
to MOVE a relative symlink does not update the symlink relative target.
LOCK is on the resource (e.g. a symlink), not the target of the symlink.
COPY replaces the resource (e.g. a symlink), not the target of the
symlink. There are only a few examples of possibly many more reasons
why using symlinks in a WebDAV-writable collection is unsafe.
NB: r->tmp_buf == srv->tmp_buf (pointer is copied for quicker access)
NB: request read and write chunkqueues currently point to connection
chunkqueues; per-request and per-connection chunkqueues are
not distinct from one another
con->read_queue == r->read_queue
con->write_queue == r->write_queue
NB: in the future, a separate connection config may be needed for
connection-level module hooks. Similarly, might need to have
per-request chunkqueues separate from per-connection chunkqueues.
Should probably also have a request_reset() which is distinct from
connection_reset().
Glenn Strauss