| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| | |
These direct accesses are probably more optimized, but weird when the
module API has methods for these things.
|
| |
| |
| |
| |
| |
| |
| | |
Allows testing e.g. opportunistic writes or other settings easily in CI
or otherwise without editing the config file.
make integration-test PROSODY_NETWORK_SETTINGS='{"opportunistic_writes":true}'
|
| |
| |
| |
| |
| |
| |
| | |
To make it easier to test select and event without having to edit the
config file, e.g. in CI.
make integration-test PROSODY_NETWORK_BACKEND=event
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
net.http.files serving a big enough file on a fast enough connection
with opportunistic_writes enabled could trigger a stack overflow through
repeatedly serving more data that immediately gets sent, draining the
buffer and triggering more data to be sent. This also blocked the server
on a single task until completion or an error.
This change prevents nested opportunistic writes, which should prevent
the stack overflow, at the cost of reduced download speed, but this is
unlikely to be noticeable outside of Gbit networks. Speed at the cost of
blocking other processing is not worth it, especially with the risk of
stack overflow.
|
| |
| |
| |
| | |
It isn't quite an error.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When opportunistic writes are enabled this reduces the number of
syscalls and TCP packets sent on the wire.
Experiments with TCP Fast Open made this even more obvious.
That table trick probably wasn't as efficient. Lua generates bytecode
for a table with zero array slots and space for two entries in the hash
part, plus code to set [2] and [4]. I didn't verify but I suspect it
would have had to resize the table when setting [1] and [3], although
probably only once. Concatenating the strings directly in Lua is easier
to read and involves no extra table or function call.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may speed up client-first protocols (e.g. XMPP, HTTP and TLS) when
the first client data already arrived by the time we accept() it.
If LuaSocket supported TCP_DEFER_ACCEPT we could use that to further
increase the chance that there's already data to handle.
In case no data has arrived, no harm should be done, :onreadable would
simply set the read timeout and we'll get back to it once there is
something to handle.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The :init method is more suited for new outgoing connections, which is
why it uses the connect_timeout setting.
Depending on whether a newly accepted connection is to a Direct TLS port
or not, it should be handled differently, and was already. The :starttls
method sets up timeouts on its own, so the one set in :init was not needed.
Newly accepted plain TCP connections don't need a write timeout set, a
read timeout is enough.
|
| |
| |
| |
| |
| |
| | |
This should make sure that if there's data left to be written when
closing a connection, there's also a timeout so that it doesn't wait
forever.
|
| |
| |
| |
| | |
Things can behave unexpectedly when fed ANSI escape codes.
|
| |
| |
| |
| |
| | |
Useful for disabling certain behavior, ANSI colors etc when not
connected to a terminal.
|
| | |
|
| |
| |
| |
| |
| |
| | |
In some cases you might end up with both 'xmpp.example.com' and
'xmpp.example.com.', which are the same thing so no point in doing the
same checks twice.
|
| |
| |
| |
| |
| |
| | |
Clients would try to connect and receive an error or timeout, increasing
the time it takes to establish a connection. Probably not what you want.
If you really want IPv6 or IPv4 disabled, best remove the A or AAAA record.
|
| |
| |
| |
| | |
Why would you do this?!
|
| |
| |
| |
| |
| | |
If you set 'use_ipv4 = false' then you probably don't care much for the
host not resolving to the IPv4 address, and same with 'use_ipv6'.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may have mistakenly caused link-local addresses to be considered
global. May have caused mod_s2s and prosodyctl check dns to behave
incorrectly on networks using link-local IPv4 addresses. By my
guesstimate, these are extremely rare. Probably minimal impact beyond
a bit longer to establish s2s and some possible confusion from
prosodyctl check dns results.
Ref RFC 3927
|
| | |
|
| |
| |
| |
| |
| | |
This should a) prevent injection of text that looks like legitimate log
lines and b) not mangle tracebacks.
|
| |
| |
| |
| |
| | |
Made the pattern match a longer range than intended, but with no effect
since those characters are not present in the 'control_symbols' table.
|
| |
| |
| |
| |
| |
| | |
If unbound was initialized prior to this then the config change here
wouldn't apply, and it will again think that 127.0.1.1 has been found
in DNS.
|
| | |
|
| |
| |
| |
| |
| | |
This replaces an earlier method in a private extension that logged
pretty-printed XML, which broke due to the escaping added in util.format
|
| | |
|
| |
| |
| |
| | |
This will be used by the console logger for pretty printing.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've had this color theme in a local debug module for some time and I
quite like it. The colors are from the XMPP logo.
Removes extra XML serialization implementation in favor of the standard
one. Also removes recursive str=str..more string building.
The new two-level gsub has the accumulator in C space so shouldn't be
too bad. The inner gsub calls use no callback, so should be fast and
not create all that much garbage.
No serious benchmarking has been done, but who cares if it looks nice?
|
| |
| |
| |
| |
| |
| | |
Always enable pretty printing if util.termcolours is available
util.termcolours can be nooped out to disable pretty printing.
|
| |
| |
| |
| |
| |
| |
| | |
This should offer some protection against doing evil things to
terminals. Doesn't protect against pure broken UTF-8 garbage however.
See #734
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
thought)
Character sequences could be split across chunk boundaries. Would require a bunch
of code to make that work reliably.
Only apply front_consumed on first chunk, and adjust buffer_pos accordingly.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Makes merges and diffs easier to read and deal with, especially when
using tools to gather options from the codebase.
|
| |
| |
| |
| | |
Goal is to have some accountability for these privileged actions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This doesn't really make sense today. It doesn't even work with
mod_auth_internal_hashed, which should be the default. And even with a
supporting authentication module, why would we just hand out the
password? One use case may be to recover a forgotten password. While not
yet included with Prosody, there are better ways to handle forgotten
passwords, usually by resetting them to a new password.
|
| |
| |
| |
| |
| |
| | |
Fixes #1643
API change: The argument to archive_itemstore() changes type to integer
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because during startup, if all items are provided by a different module
(e.g. mod_turn_external) then this would log a scary warning even if
everything is fine after that other module has been loaded.
This way, any persistent problematic state is reported in the console.
Errors with individual items should still be reported by prepare().
Now, if you load mod_external_services alone without configuring any
services, no error or warning is reported in the log, but maybe that's
not so bad with it reported in the console.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This ensures that problems with entries added other modules, e.g.
mod_turn_external, are reported on startup. However, this depends on
load order and whether a `module:depends()` call comes before the
`module:add_item()` call. A followup commit will do something about
that.
|
| | |
|
| |
| |
| |
| | |
Should have been removed in the previous commit.
|
| |
| |
| |
| | |
See previous commit to mod_c2s: a62146353528
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The :info() method has been observed to return nothing ... sometimes.
Unclear what causes it. Perhaps the TLS connection was shut down or
hasn't fully settled?
The LuaSec code has code paths that return nothing or nil, error, so it
is best to guard against it.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Since there is now support for SNI with per-host certificates as well as
support in `prosodyctl check dns`.
Previous "support" was just the 'legacy_ssl' option, which didn't have
much other supporting code.
|
| |
| |
| |
| | |
^C^V
|