After recent changes, '--foo bar' was working, but '--foo=bar' was not. The
test had a typo (?) (bar != baz) and because util.argparse is not strict by
default, the typo was not caught.
The typo caused the code to take a different path, and bypassed the buggy
handling of --foo=bar options.
I've preserved the existing test (typo and all!) because it's still an
interesting test, and ensures no unintended behaviour changes compared to the
old code.
However I've added a new variant of the test, with strict mode enabled and the
typo fixed. This test failed due to the bug, and this commit introduces a fix.
Inspired by something MattJ said
Allows retrieving config values from files which are expected to be
relative to the config directory, extending on the ENV_ method of
retrieving config values from outside the config file.
- FileLine retrieves the first line, stripping any trailing newline
- FileContents reads the whole file
- FileLines reads lines into an array
Allows granting read only access to other sets of users using a separate
access control capability, which makes sense as some properties may be
intended to be public but read-only.
pkey_meth_derive: to derive a shared symmetric key from two ECC keys
pkey_meth_public_raw: to get the raw form of the public key
import_public_ec_raw: to import the raw form of the public key
generate_p256_keypair: key generation for the P-256 curve
It was mainly used to determine whether to try IPv6 or IPv4 first,
following the rules for this in the RFC.
Now we always try IPv6 and IPv4 at roughly the same time, thus there no
need to carry these rules.
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.
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.
This is happens if the account is new and doesn't have any bookmarks
yet, which is not a problem.
Rarely seen since most clients currently use the older version of
XEP-0084 stored in XEP-0049 rather than in PEP, but at least one
(Converse.js )does.
One scenario in which this would show up often is with Converse.js as a
guest chat using anonymous authentication, where all "accounts" would
always be new and not have any bookmarks. This scenario probably does
not need to have mod_bookmarks at all, but if enabled globally it would
likely become loaded onto the VirtualHost unless explicitly disabled.
The JSON Schema specification says that schemas are objects or booleans,
and that the 'type' property is optional and can be an array.
This module previously allowed bare type names as schemas and did not
really handle booleans.
It now handles missing 'type' properties and boolean 'true' as a schema.
Objects and arrays are guessed based on the presence of 'properties' or
'items' field.
MattJ reported a curious issue where validation did not work as
expected. Primarily that the "type" field was expected to be mandatory,
and thus leaving it out would result in no checks being performed.
This was likely caused by misreading during initial development.
Spent some time testing against
https://github.com/json-schema-org/JSON-Schema-Test-Suite.git and
discovered a multitude of issues, far too many to bother splitting into
separate commits.
More than half of them fail. Many because of features not implemented,
which have been marked NYI. For example, some require deep comparisons
e.g. when objects or arrays are present in enums fields.
Some because of quirks with how Lua differs from JavaScript, e.g. no
distinct array or object types. Tests involving fractional floating
point numbers. We're definitely not going to follow references to remote
resources. Or deal with UTF-16 sillyness. One test asserted that 1.0 is
an integer, where Lua 5.3+ will disagree.
The second return value is (not insensibly) assumed to be an error. Instead of
returning a value there in the success case, copy the positional arguments
into the existing opts table.
It iterates over childtags, so a template like {foo|each{...}} would be
equivalent to root:childtags("foo"), while a deeper query needs the bit
that becomes arguments to :childtags as an argument to each, e.g.
{foo/bar|each(baz)} would behave like
root:get_child("foo"):get_child("bar"):childtags("baz")
