| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\| |
|
| |
| |
| |
| |
| |
| | |
Fixes https://prosody.im/security/advisory_20210722/
Backs out 4d7b925652d9
|
| |
| |
| |
| |
| | |
Optimizes away all the processing on every message in case the
end-result is zero history.
|
| |
| |
| |
| |
| |
| | |
If this seems backwards, that' because it is but the API isn't really
designed to easily pass along details from each resolution step onto the
next.
|
| |
| |
| |
| |
| |
| | |
Removes the need to enable DANE with two separate settings.
Previously you had to also set `ssl = { dane = true }` to activate DANE
support in LuaSec and OpenSSL.
|
| |
| |
| |
| |
| | |
Previous commit adds a workaround, so this doesn't mutate global state
anymore, only per-connection 'extra' state as originally intended.
|
| |
| |
| |
| |
| |
| |
| | |
This way 'extra' is unique for each connect() instance, making it safer
to mutate it, while inheriting the global settings.
See 926d53af9a7a for some more context.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lets various supporting editors know what indentation style should
be used for files in the repo. See https://editorconfig.org/
Coding style for Lua files is described in `doc/coding_style.md`
The 3-space indentation in `configure` comes from its LuaRocks
inheritance.
`doc/doap.xml` is normalized with `xmllint` which spits out 2-space
indentation.
|
| |
| |
| |
| |
| | |
This could happen with Dialback-only connections or others that were
missing the stream 'to' attribute.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given an incoming <stream:stream from="example.com"> this line would
have mistakenly reported the 'from' as the local host. Neither are
technically required and may be missing, especially on connections used
only for Dialback.
Outgoing connections initiated by Prosody always have 'from_host' and
'to_host', so it is safer to check it this way.
|
| |
| |
| |
| |
| |
| |
| | |
Caused "attempt to index a string value (local 'data')", but only if
keep_buffers is set to false, which is not the default.
Introduced in 917eca7be82b
|
| |
| |
| |
| |
| | |
Read and write timeouts should usually match whether we want to read or
write.
|
| |
| |
| |
| | |
Should avoid rare but needless timer interactions
|
| |
| |
| |
| |
| | |
Instead of removing and readding the timer, keep it and adjust it
instead. Should reduce garbage production a bit.
|
| |
| |
| |
| |
| |
| |
| | |
Only real difference between the read and write timeouts is that the
former has a callback that allows the higher levels to keep the
connection alive, while hitting the later is immediately fatal. We want
the later behavior for TLS negotiation.
|
| |
| |
| |
| |
| |
| | |
Saves a function call. I forget if I measured this kind of thing but
IIRC infix concatenation is faster than a function call up to some
number of items, but let's stop at 2 here.
|
| |
| |
| |
| |
| |
| |
| | |
writebuffer is now string | { string }
Saves the allocation of a buffer table until the second write, which
could be rare, especially with opportunistic writes.
|
| |
| |
| |
| |
| | |
Reusing an already existing buffer table would reduce garbage, but
keeping it while idle is a waste.
|
| |
| |
| |
| |
| | |
So that if a write ends up writing directly to the socket, it gets the
actual return value
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A timeout value less than 0.001 gets turned into zero on the C side, so
epoll_wait() returns instantly and essentially busy-loops up to 1ms,
e.g. when a timer event ends up scheduled (0, 0.001)ms into the future.
Unsure if this has much effect in practice, but it may waste a small
amount of CPU time. How much would depend on how often this ends up
happening and how fast the CPU gets trough main loop iterations.
|
| |
| |
| |
| | |
Should Plugin really be first? What order makes the most sense?
|
| |
| |
| |
| |
| | |
This hides a whole bunch of subcommands tho, maybe those should be
explicitly listed?
|
| | |
|
| |
| |
| |
| |
| | |
Along with infrastructure for the other commands that live in external
modules.
|
| |
| |
| |
| | |
Nagle increases latency and is the bane of all networking!
|
| |
| |
| |
| |
| |
| |
| | |
Activated by setting config.tcp_keepalive to a number, in seconds.
Defaults to 2h.
Depends on LuaSocket support for this option.
|
| |
| |
| |
| |
| |
| | |
In case one wishes to enable this for all connections, not just c2s
(not Direct TLS ones, because LuaSec) and s2s. Unclear what use these
are, since they kick in after 2 hours of idle time.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Good to know if it fails, especially since the return value doesn't seem
to be checked anywhere.
Since LuaSec-wrapped sockets don't expose the setoption method, this
will likely show when mod_c2s tries to enable keepalives on direct tls
connections.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Couldn't use those with the host being deactivated.
Problem: This kicks in on reload, which isn't needed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Increases log level for stream conditions that could indicate a problem
on our end, especially programming errors like invalid XML, or the
remote server saying that our certificate is invalid, since these should
be investigated.
Non-issues like closing of idle streams are lowered to debug since it's
mostly noise.
Other issues left at info are mostly about changes to the remote server,
e.g. complete or partial shutdown.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Reduces the number of left-over timers to handle after many s2s
connections were started, leaving only the ones related to incomplete
connections.
|
| |
| |
| |
| |
| |
| | |
Skips a roundtrip through the main loop in case client-first data is
available already, if not then :onreadable() will set the appropriate
timeout.
|
| | |
|
| |
| |
| |
| |
| | |
There's the theory that the socket isn't the same before/after wrap(),
but since epoll operates on FD numbers this shouldn't matter.
|
| |
| |
| |
| | |
The :init() method sets a different timeout than the TLS related methods.
|
| |
| |
| |
| |
| |
| | |
Since TLS is a client-first protocol there is a chance that the
ClientHello message is available already. TLS Fast Open and/or the
TCP_DEFER_ACCEPT socket option would increase that chance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
So there's :startls(), :inittls() and :tlshandshake()
:starttls() prepares for plain -> TLS upgrade and ensures that the
(unencrypted) write buffer is drained before proceeding.
:inittls() wraps the connection and does things like SNI, DANE etc.
:tlshandshake() steps the TLS negotiation forward until it completes
|
| | |
|
| |
| |
| |
| |
| |
| | |
This should probably never happen, but probably does anyways.
A debug message would show the truth of the matter.
|
| |
| |
| |
| |
| | |
Nicer to get rid of a conditional that covers such a large portion of a
pretty big function.
|
| |
| |
| |
| |
| | |
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.
|