| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(fixes #1763) (thanks rgd)
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
return foo and foo() crops multiple return values to a single one, so
any second return values etc were last, mostly error details.
Introduced in 7e9ebdc75ce4
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a Linux(?) socket option that delays the accept signal until
there is data available to read. E.g. with HTTP this might mean that a
whole request can be handled without going back trough another turn of
the main loop, and an initial client <stream> can be responded to.
This may have effects on latency and resource use, as the server does
not need to allocate resources until really needed.
|
| |
| |
| |
| |
| | |
Since it provides some protection and error handling in the form of
logging.
|
| |
| |
| |
| | |
Reduces the side effects of wrapsocket()
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Requires a patch to LuaSocket adding this socket option,
https://github.com/lunarmodules/luasocket/pull/378
sysctl tweaks
net.ipv4.tcp_fastopen=3
net.ipv4.tcp_fastopen_blackhole_timeout_sec = 0
net.ipv4.tcp_fastopen_key=$(</proc/sys/kernel/random/uuid)
Disabled by default since it an advanced performance tweak unlikely to
be needed by most servers.
|
|\| |
|
| |
| |
| |
| | |
This error is an error, therefore it should be at the error level
|
| |
| |
| |
| |
| | |
This mirrors the behaviour with net.dns and avoids the initialization
issue in #1737
|
| |
| |
| |
| |
| | |
server_select is used in e.g. storagemanager tests, and some of the CI
runners are lacking LuaSec, which resulted in failures.
|
| |
| |
| |
| |
| |
| | |
We at some point decided that it was okay to have a hard dependency the
TLS library. Especially here since this module is meant to contain all
LuaSec specifics.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This now requires that the network backend exposes a tls_builder
function, which essentially wraps the former util.sslconfig.new()
function, passing a factory to create the eventual SSL context.
That allows a net.server backend to pick whatever it likes as SSL
context factory, as long as it understands the config table passed by
the SSL config builder. Heck, a backend could even mock and replace the
entire SSL config builder API.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For this, various accessor functions are now provided directly on the
sockets, which reach down into the LuaSec implementation to obtain the
information.
While this may seem of little gain at first, it hides the implementation
detail of the LuaSec+LuaSocket combination that the actual socket and
the TLS layer are separate objects.
The net gain here is that an alternative implementation does not have to
emulate that specific implementation detail and "only" has to expose
LuaSec-compatible data structures on the new functions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Connection attempts that failed the Happy Eyeballs race were not
unreferenced and would accumulate.
Tested by inspecting the 'pending_connections_map' after establishing
s2s with a s2s target where the IPv6 port has a -j DROP rule causing it
to time out and the IPv4 attempt wins the race.
Expected is that the losing connection stays around until net.server
timeouts kick in where it should be removed. The map table should tend
towards being empty during idle times.
|
| | |
|
| |
| |
| |
| |
| | |
This could lead to failure being reported too early, even if some connections
have not yet failed.
|
| | |
|
| |
| |
| |
| | |
RFC 8305
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
...and prepare for Happy Eyeballs
|
|/
|
|
| |
#NotHappyEyeballs
|
|
|
|
|
|
| |
Words, sometimes I wonder how they even work
Maybe I missed something.
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
versions
|
|
|
|
| |
Improves performance since the whole procedure is done in C
|
| |
|
| |
|
|
|
|
| |
Dare to enable by default?
|
|
|
|
|
|
| |
Only allowing it to be passed directly makes it hard to combine plain
(i.e. starttls) and Direct TLS connections in the same connection
resolution procedure. But now we can, using chained resolvers!
|
|
|
|
| |
Say if you wanted to try both _xmpp and _xmpps services
|
|
|
|
| |
Thanks Martin bringing this case to attention
|
|
|
|
|
| |
Modules using ids for logging should not need the now pretty large
medium one.
|
|
|
|
|
| |
Not a particularly user-friendly error message, but better than "unable
to resolve service" and having no clue where it came from.
|
|
|
|
|
|
|
|
|
|
| |
With opportunistic writes enabled, writes can return what :onwritable()
returns, thus :onwritable() should return something sensible at each
spot.
Should prevent whatever caused
> Error writing to connection: (nil)
Tho this was probably harmless
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the connection is closed by the peer, any buffered data is given a
last chance to be sent (see f27b9319e0da). If the connection is Really
closed, no attempt to write will occur, instead epoll will raise the
error flag and :onreadable() will be invoked again, where it will try to
:close() again for the same reason, thus looping until the connection
somehow gets destroyed.
By clearing the _connected flag, the second time it passes :onreadable()
it should go directly to :destroy(), breaking the loop.
Thanks Link Mauve for reporting
|
|
|
|
|
|
|
|
|
|
| |
ff4e34c448a4 broke the way net.http.server streams downloads from disk
because it made writes from the ondrain callback no longer reset the
want-write flag, causing the download to halt.
Writes from the predrain handler still must not trigger anything but
additions to the buffer, since it is about to do all the socket writing
already.
|
|
|
|
|
|
| |
Opportunistic writes sure do complicate things. This is especially
intended to avoid opportunistic_writes from within the onpredrain
callback.
|
|
|
|
|
| |
E.g. "connection refused" over one IP version instead of NoError for the
other IP version.
|
|
|
|
|
|
|
|
| |
Previously it would only say "unable to resolve server" for all DNS
problems. While "NoError in A lookup" might not make much sense to
users, it should help in debugging more than the previous generic error.
Friendlier errors will be future work.
|