It seems this is actually allowed by the RFCs; although it is intended
as HTTP/1.0 backward compatibility, and HTTP/1.1 servers (backends)
really should do better.
... so li_stream_simple_socket_close doesn't need to acquire (when the rc might already be 0).
Instead call li_iostream_reset in all places that didn't acquire before,
and drop the acquire.
- use decoded path instead of orig raw path (which includes the query
string); the decoded path should be safe, and we also really don't
need to support any "raw" handling - we're at the filesystem level
Even if they shouldn't (due to HTTP/1.0 or Connection; close) some
backends send HTTP/1.1 without Connection: close, and use Content-Length
to signal end of response (and don't close the connection, as they wait
for another request).
Now Content-Length is used to find the end of the response (chunked
transfer-encoding was already supported).
mod_proxy now signals HTTP/1.1, but also sends "Connection: close": it
doesn't reuse the connection yet.
readdir_r is deprecated in glibc due to serious memory handling issues
in the API: one cannot pass the size of the allocated dirent.
glibc authors claims readdir is thread-safe in modern implementations,
and expect POSIX to require it in a future version.
No way to check whether readdir is thread-safe though :(
("thread-safe" in this context means different directory streams, which
is good enough.)
Also remove li_dirent_buf_size.
- static, flv: return 414
- dirlist, pathinfo: treat as not-existing (i.e. no handling)
- also return 500 instead of closing the connection when stat/open
fails an unhandled error
- explicit return instead of switch-case fallthrough (no semantic
change) in actions.c
- simulates an implicit "<![CDATA[ ... ]]>" mode
- if the blocks consists of a single CDATA node entities are not decoded;
instead the CDATA content is used directly.