| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous behaviour:
- publisher was always included in PEP notifications
- publisher was never included in get_items requests
New behaviour:
- publisher is included in both notifications and retrieval if
itemreply == publisher
- publisher is not ever included if itemreply ~= publisher
|
|
|
|
|
|
|
|
| |
This combines the two most common store types, which modules often end up
opening with both interfaces separately anyway.
As well as combining them, I've taken the opportunity to improve some of the
method names to make them clearer.
|
|
|
|
| |
Absolute references, weird fractions, unevaluatedProperties???
|
|
|
|
| |
These seem to be using absolute URI references, Not Yet Implemented
|
| |
|
| |
|
|\ |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| | |
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 required by PASETO v3.local
|
| |
| |
| |
| | |
These are needed for PASETO v3.local.
|
| |
| |
| |
| |
| | |
Don't need the function, more compact to just reference the same
reference table.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In this API, a 'node' is always a simple text string. Sometimes the caller may
have a more complex structure representing a node, but the hash ring is really
only concerned with the node's name.
This API change allows :add_nodes() to take a table of `node_name = value`
pairs, as well as the simple array of node names previously accepted.
The 'value' of the selected node is returned as a new second result from
:get_node().
If no value is passed when a node is added, it defaults to `true` (as before,
but this was never previously exposed).
|
| |
| |
| |
| | |
sequential style
|
|\| |
|
| | |
|
| |
| |
| |
| | |
Result of mutation testing. One mutant remaining.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Result of mutation testing
Remaining mutants are mostly relating to the math.type() fallback.
Another case being that array[#array+1] == array[#array+2] and thus
doesn't matter.
|
| |
| |
| |
| | |
Found via mutation testing.
|
| | |
|
| |
| |
| |
| | |
(98% mutant score, single remaining mutant is a string.sub equivalent)
|
| |
| |
| |
| | |
Found via mutation testing.
|
|\| |
|
| |
| |
| |
| | |
Also touching on how arrays are indistinguishable from tables in Lua
|
| |
| |
| |
| | |
Full-URI references are not implemented
|
| |
| |
| |
| | |
Piped trough `sort -g`
|
| |
| |
| |
| | |
You guessed it, mutation testing.
|
| | |
|
| |
| |
| |
| | |
Found via mutation testing.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lines don't appear to do anything useful, and all tests pass when they
are removed. Discovered via mutation testing.
I added extra tests to exercise this code, because I wasn't certain that there
were no side-effects caused by removal. Everything appears to be fine, thanks
to the "pending" check at the start of promise_settle().
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Found this number in a hat.
Sleepy time. Good night.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PASETO spec recommends - no, *requires* - that implementations enforce
type safety for keys, and e.g. do not pass them around as arbitrary byte
strings. Typed wrapper objects are recommended.
I originally followed this advice when starting the lib. However, key wrapping
and type safety is now also a feature of util.crypto. All we're doing is
duplicating it unnecessarily with this additional wrapper code.
|
| |
| |
| |
| |
| | |
Unfortunately there are only a few relevant ones, but they did help catch some
bugs.
|
| |
| |
| |
| | |
Except 'none'. Not implementing that one.
|
| | |
|
| |
| |
| |
| |
| | |
Now we can consistently apply the same tests to every algorithm, instead of
duplicating code.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In many cases code will be either signing or verifying. With asymmetric
algorithms it's clearer and more efficient to just state that once, instead of
passing keys (and possibly other parameters) with every sign/verify call.
This also allows earlier validation of the key used.
The previous (HS256-only) sign/verify methods continue to be exposed for
backwards-compatibility.
|
| |
| |
| |
| |
| | |
Specifically, ED25519 key generation/import/export, sign/verify operations,
and AES encrypt/decrypt.
|
| |
| |
| |
| |
| | |
Some fiddling is required now in error_reply() to ensure the cursor is in the
same place as before this change (a lot of code apparently uses that feature).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes you only care about a single attribute, but the child tag
itself may be optional, leading to needing `tag and tag.attr.foo` or
`stanza:find("tag@foo")`.
The `:find()` method is fairly complex, so avoiding it for this kind of
simpler use case is a win.
|