Handling signal events the same way as all other events makes sense and
seems safer than the signal handling just jumping around in C and
messing with Lua states.
This information is sometimes necessary in the context where we have a
connection that we know (or believe to be) associated with an incoming HTTP
request.
For example, it can be used to retrieve the IP address of a request (which may
differ from the IP address of the connection, due to X-Forwarded-For and co).
Thanks to the Jitsi team for highlighting this gap in the API.
This ensures that we support responses without a content-length header, and
allow streaming them through the streaming handler interface. An example of
such a response would be Server-Sent Events streams.
Unregistering the response before sending the trailer of the chunked
transfer encoding prevents opportunistic writes from being invoked and
running this code again when, which may cause an error when closing the
file handle a second time.
Normally the file size is known, so no chuck headers are sent.
add_defaults() is supposed to merge 3 tables, the defaults in
luaunbound, the defaults from prosody and any config from the prosody
config file. In the case where no `unbound={}` has been in the config,
it skips over the merge and returns only the prosody built-in defaults.
This results in libunbound skipping reading resolv.conf and uses its
default behavior of full recursive resolution.
Prior to #1737 there were only two tables, the luaunbound defaults and
the prosody config, where bypassing the merge and returning the former
did the right thing.
Fallback code for not having either the string.pack and string.unpack
functions available in Lua 5.4 or the struct lib is no longer needed
since the struct lib was imported as util.struct in 3ce3633527af
Otherwise requests with Connection: close would be stuck in the async
wait that starts after the handle_request() call.
Together with the new async debugging, this makes the async thread stay
in the set of waiting runners forever, where previously it would simply
be garbage collected.
This should speed up repeated requests to the same site by keeping their
connections around and sending more requests on them.
Sending multiple requests at the same time is not supported, instead a
request started while another to the same authority is in progress would
open a new one and the first one to complete would go back in the pool.
This could be investigated in the future.
Some http servers limit the number of requests per connection and this
is not tested and could cause one request to fail, but hopefully it will
close the connection and prevent it from being reused.
mod_http_errors normally sets the Content-Type header via the response
object, which isn't available when handling these uncaught errors.
Without a Content-Type header the browser is forced to guess, which may
or may not result in something sensible.
Since these are noisy and we have the thing in util.helpers to log
events fired.
The new status line events are meant to replace these as they include
more useful info.
