| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
of unix sockets)
|
|
|
|
| |
(if util.poll is found)
|
|
|
|
|
|
| |
The internal implementations don't use it, but this causes onreadable
and onwritable of watchfd to receive the conn as they do in other
backends.
|
|
|
|
|
|
|
|
|
| |
This changes the code to call onconnect when the first data is sucessfully
read or written, instead of simply when the socket first becomes writable.
A writable socket can mean a connection error, and if the client already
sent some data it may get passed to onincoming before processing writable
sockets. This fixes the issue.
|
| |
|
|
|
|
|
| |
This would help pinpoint if a crash happens during the handshake, which
has occurred a few times, e.g. like https://github.com/brunoos/luasec/issues/75
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Some lines seem to have gotten the wrong indentation, possibly caused by
Meld which often ignores lines with only whitespace changes and leaves
their previous indentation.
|
| |
| |
| |
| | |
Oversight in 955e54e451dc when this was added.
|
| |
| |
| |
| |
| |
| | |
`if timer ...` suggests that this was intended, but it did not work
because net.timer depends on net.server which refuses to be loaded
outside of Prosody.
|
| |
| |
| |
| |
| | |
Each basic resolver was only used once and not kept around to try any
IP addresses but the first one found.
|
| |
| |
| |
| |
| |
| |
| | |
These are triggered all the time by random HTTPS connections, so they
are mostly just useless noise. When you actually do need them, you
probably have debug logging enabled too, since these messages are fairly
useless without more context.
|
| |
| |
| |
| | |
This mirrors what server_event does.
|
| |
| |
| |
| |
| | |
The code expects ready() to be called twice, but with IPv4 or v6
disabled it would only be called once.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Sometimes all these things just drown out the logs you are interested
in with low-level socket noise.
Enabled since it's still new and experimental.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Saves creating a string that'll be identical to buffer[1] anyways, as
well as a C function call. Depending on Lua version and length of the
string, this could be reusing an interned string, but a longer one would
probably be duplicated for no reason.
Having exactly one item in the buffer seems like it would be fairly
common, but I have not done an extensive study. If opportunistic writes
are enabled then it will be even more likely.
This special case could be optimized like this in table.concat but it
does not look like it is.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Stanza errors can also have numbers but these are a legacy thing and
rarely used, except in MUC. HTTP errors on the other hand always have a
number.
|
| |
| |
| |
| | |
Timer API of passing wallclock time remains
|
| |
| |
| |
| |
| | |
Relative to current time instead of absolute time, in preparation for
switching to monotonic time.
|
| |
| |
| |
| | |
This won't make sense if we switch to monotonic time
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In :onreadable, if there is still buffered incoming data after reading
from the socket (as indicated by the :dirty method, usually because
LuaSocket has an 8k buffer that's full but it read a smaller amount),
another attempt to read is scheduled via this :pausefor method. This is
also called from some other places where it would be pointless to read
because there shouldn't be any data.
In the delayed read case, this should report that the socket is "dirty".
If it reports that the socket is "clean" then the question is where
the buffer contents went?
If this doesn't get logged after the scheduled time (0.000001s by
default) then this would suggests a problem with timer or scheduling.
|
| |
| |
| |
| |
| | |
Default Address Selection algorithm is not applied, resulting in a
strong bias towards IPv4.
|
| |
| |
| |
| | |
And mention issue numbers: #1246, #1428 and #1429
|
| |
| |
| |
| | |
For consistency. None of the other implementations do this.
|
| |
| |
| |
| |
| |
| | |
Shouldn't hurt. Revert if it turns out it does.
Supported in LuaSec 0.8. Should be ignored otherwise.
|
| |
| |
| |
| |
| | |
We want to figure out what situations the double ondisconnect happens in, and
aim to fix the root cause in the future.
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| | |
IP literals will not work with SRV records anyways.
Fixes s2s with IP literals.
|
|\| |
|
| | |
|
| |
| |
| |
| |
| | |
This is to prepare for fixing #1459. An IPv6 literal in [ ] brackets
does not pass IDNA and resolving it fails there.
|
| |
| |
| |
| | |
As with 0e1701197722
|
| | |
|
| |
| |
| |
| | |
As with 0e1701197722
|
| | |
|