| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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.
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Should call timers less frequently when many sockets are waiting for
processing. May help under heavy load.
Requested by Ge0rG
|
|
|
|
|
|
|
|
|
|
| |
This is not a pretty way to signal this... but it is the current API
interface:inittls() is a new code path which did not go past the point
in interface:starttls() where it set starttls to false, leading mod_tls
to offer starttls on direct TLS connections
Thanks Martin for discovering.
|
|
|
|
|
|
| |
The intent is to ensure 'ondisconnect' only gets called once, while
giving buffered outgoing data a last chance to be delivered via the
:close() path in case the connection was only shutdown in one direction.
|
|
|
|
|
|
|
|
| |
Before 22825cb5dcd8 connection attempts that failed (e.g. connection
refused) would be immediately destroyed. After, it would schedule
another write cycle and then report 'ondisconnect' again when failing.
Thanks Martin for reporting
|
|\ |
|
| |
| |
| |
| | |
Should ensure shutdown even if sockets somehow take a very long to get closed.
|
| |
| |
| |
| |
| | |
This should ensure that sockets get closed even if they are added after
the quit signal. Otherwise they may keep the server alive.
|
| |
| |
| |
| | |
Seems to have happened in 6427e2642976, probably because of Meld
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead try to write any remaining buffered data. If the write attempt
also fails with "closed" then there's nothing we can do and the socket
is gone.
This reverts what appears to be a mistakenly included part of c8aa66595072
Thanks jonas’ for noticing
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously it was unclear whether "client port" was the port that the
client connected to, or from. I hereby declare that the client port is
the source port and the server port is the destination port.
Incoming and outgoing connections can be distinguished by looking at
the_server reference, which only incoming connections have.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To be removed in the future, but not right now. Give the log warning a
chance to prod anyone who might have network_backend="select" in their
config first.
There's also things built on Verse which uses server_select.lua, which
will need to be updated somehow.
|
| |
| |
| |
| |
| |
| |
| | |
Previously it would have gone for server_select if util.poll was for
some reason not available, which should be never these days. And even if
it was, best to flush it out by throwing loud errors so users notice.
Then they can work around it by using select until we delete that one.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes that selecting libevent when unavaibalbe would fall back to select
instead of epoll, even if that's available.
This way, we only have to update it in once place when choosing a new
default.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a case like this the timer would not be readded:
addtimer(1, function(t, id)
stop(id)
return 1
end);
|
|\| |
|
| |
| |
| |
| |
| |
| |
| | |
Likely affected rescheduling but have no reports of this.
After readding a timer, it would have been issued a new id. Rescheduling
would use the previous id, thus not working.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if surrounding code was not configuring the TLS context
used default in net.http, it would not validate certificates at all.
This is not a security issue with prosody, because prosody updates the
context with `verify = "peer"` as well as paths to CA certificates in
util.startup.init_http_client.
Nevertheless... Let's not leave this pitfall out there in the open.
|
| |
| |
| |
| |
| |
| | |
Only relevant because a "dirty" connection (with incoming data in
LuaSocket's buffer) does not count as "readable" according to epoll, so
special care needs to be taken to keep on processing it.
|