Prevent Bad Things from happening when the buffer gets full.
This of course opens up the possibility of intentionally killing
connections by sending much stuff, which need to be mitigated with rate
limits elsewhere.
Problem: The string slice operations when a lot of data gets buffered
ends up being expensive and memory-consuming. We have util.dbuffer for
precisely this kind of thing.
I want to keep the behavior of writebuffer being upgraded from nil to a
string to full buffer since the last step involves three table
allocations, where the previous buffer method only used one. Avoiding
those allocations for simple writes like white space keep alive feels
like it would keep memory churn down.
This work was started in 2020
This enables accepting admin stream socket (UNIX) connections trough the
same procedures as any other (TCP) socket, which avoids problems caused
by using the wrapclient API, which ends up discarding early data due to
only expecting early connection failure.
Fixes#1867
Allows creating listening sockets and accepting client connections
before Prosody starts.
This is unlike normal Prosody dynamic resource management, where ports
may added and removed at any time, and the ports defined by the config.
Weird things happen if these are closed (e.g. due to reload) so here we
prevent closing and ensure sockets are reused when opened again.
libunbound does not tell us the whole chain of CNAMEs, only the final
canonical name.
This is to aid in debugging since it will only be shown in the shell.
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.