Previously the error messages said that it failed to "publish" to PEP, but
sometimes a sync involves removing items, which can be confusing.
The log was also the same for both legacy PEP and private XML bookmarks.
Having different log messages makes it easier to debug the cause and location
of any sync errors.
It appears that when:
1) The user has no bookmarks 2 node in PEP
2) The client publishes an empty bookmark set to a legacy bookmarks location
3) mod_bookmarks will attempt to purge items from the non-existent node and
log an error about the failure (item-not-found).
This new code will suppress an item-not-found error from the purge operation
in the empty-bookmarks case, and adds a log message for any other error (this
is helpful because the existing log message confusingly says it was an error
*publishing* to the node, which isn't always accurate).
Prevents ASYNC-01 due to storage interactions in a timer.
Also considered modifying mod_c2s to allow passing arbitrary closures
into its runner thread but this seems like a big step away from the
current code for just this module.
Also considered creating a dedicated runner in mod_smacks, but ensuring
continuity across module reloads might be tricky.
We could further improve this in the next major version.
This enables accepting admin stream socket (UNIX) connections trough the
same procedures as any other (TCP) socket, which avoids problems caused
by using the wrapclient API, which ends up discarding early data due to
only expecting early connection failure.
Fixes#1867
From XEP-0191:
> For message stanzas, the server SHOULD return an error, which SHOULD
> be <service-unavailable/>.
Following this may leak to a blocked JID that they have been blocked,
which seems contrary to the goal of pretending to be perpetually
offline.
Having to add these in *there* places seems less than ideal.
I would also think that advertising disco#info is a bit redundant, since
it is a requirement for everything in XMPP and if it was missing you
would get an error back.
Suggested by jstein in the chat
This option label is used by XMPP clients to explain what the option does.
a) The user should know where the data is archived.
b) The user needs a statement that can be enabled/disabled by the variable. A question would have the wrong logic here.
Because it changes the type of the 'opt_origins' variable from util.set
to the internal _items table so next time an http app is added an error
"attempt to call a nil value (method 'empty')" is triggered. The value
is not used anywhere else.
Noticed when reviewing uses of the '_items' set property.
Not reported by any users, implying this setting is rarely used.
Where gethostname or tohostname returns an invalid name, e.g. containing
underscores or something, to_ascii would reject this and return nil,
which triggers an error in the dns lookup.
Reported by prova2 in the chat, for whom tohostname returned a long name
containing underscores.
Could be used to implement custom connection methods (c.f. mod_onions)
without needing to duplicate the rest of route_to_new_session().
Adds a feature to enable detection since it can be difficult to detect
support for an event otherwise.
It should not be there afterwards. Noticed that it seems to fire some
time after resumption claiming that the queue size is nil, implying
that it may hold a reference to an expired session somehow.
Error stanzas should have an <error> element, but if you pass a
stanza without one to util.error.from_stanza() it triggers an attempt to
index a nil value, which this patch avoids.
In the conditional, it should be safe to assume error_tag is non-nil
since condition can't have those values then.
There shouldn't be one here but if there is, for some reason, it's
better to close it than have it around to wake up and possibly try to
destroy the session.
The cross_domain_* settings were added here prior to http_cors_override
being added back in 17d87fb2312a, so for a time there was no
replacement, but now there is.
This event was added in a7c183bb4e64 and is required to make mod_smacks know
that a session was intentionally closed and shouldn't be hibernated (see
fcea4d9e7502).
Because this was missing from mod_websocket's session.close(), mod_smacks
would always attempt to hibernate websocket sessions even if they closed
cleanly.
That mod_websocket has its own copy of session.close() is something to fix
another day (probably not in the stable branch). So for now this commit makes
the minimal change to get things working again.
Thanks to Damian and the Jitsi team for reporting.
When mod_admin_socket is loaded without mod_admin_shell, attempt to use
`prosodyctl shell` will appear to freeze after any input, since no
response is returned.
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.
