| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| 6.57.2.0 source code.tar.gz | 2026-08-10 | 16.4 MB | |
| 6.57.2.0 source code.zip | 2026-08-10 | 20.0 MB | |
| README.md | 2026-08-10 | 5.3 kB | |
| Totals: 3 Items | 36.4 MB | 0 | |
Distribution notice - from 1 October 2026, Maven Central receives http4k releases approximately quarterly. maven.http4k.org continues on the normal 1-2 week cadence. Both channels are supported. Background and current status: DISTRIBUTION.md (github.com)
Changelog:
- http4k-*: Upgrade versions
- http4k-connect-amazon-iot: [New module!] AWS IoT Core control plane, covering the Jobs operations (
CreateJob,DescribeJob,DescribeJobExecution,ListJobExecutionsForThing,CancelJob,DeleteJob), the stream operations devices pull files over MQTT from (CreateStream,DescribeStream,ListStreams,UpdateStream,DeleteStream) andDescribeEndpoint. - http4k-connect-amazon-iot-fake: [New module!] AWS IoT Core control plane fake, backed by a
Storage<StoredJob>and aStorage<StoredStream>. - http4k-connect-amazon-iotjobsdataplane: [New module!] AWS IoT Jobs Data Plane client - the device side of Jobs - supporting
GetPendingJobExecutions,DescribeJobExecution(including$next),StartNextPendingJobExecutionandUpdateJobExecution. It signs asiot-jobs-dataagainst the account'sdata.jobs.iot.<region>.amazonaws.comendpoint. - http4k-connect-amazon-iotjobsdataplane-fake: [New module!] AWS IoT Jobs Data Plane fake. Takes the same
Storage<StoredJob>asFakeIot, so one store passed to both gives the control plane and the device API a single jobs state. - http4k-connect-amazon-dynamodb: [Fix]
ConditionalCheckFailed.Messageis now read from themessagefield DynamoDB actually sends (lower-cased, as on its other error bodies), so deserialising a real conditional-write failure no longer throws instead of returning theItemthe caller asked for. DynamoDB Local spells itMessage, so both are accepted. The property keeps its name, so existing callers compile; the fake now emits the same spelling as AWS. - http4k-connect-amazon-sqs:
SQSMessagegainssystemAttributes(theAttributesmap SQS reports on a received message);SentMessageandSendMessageBatchResultEntrygain the previously-droppedMD5OfMessageSystemAttributes;ReceiveMessagegainsMessageSystemAttributeNames, the selector which supersedes the deprecatedAttributeNames. The attribute names SQS uses are available asMessageSystemAttributeName, andMessageFieldsDto.toSqs()is now public so the checksums can be computed outside the module. All new fields are defaulted, and each type keeps its previous primary constructor as a secondary, so existing bytecode still links (only the syntheticcopyof adata classunavoidably changes shape). - http4k-connect-amazon-sqs-fake: [Fix] A send no longer drops its FIFO fields:
MessageGroupId,MessageDeduplicationIdandMessageSystemAttributesare recorded alongside theSenderId,SentTimestampand (on a.fifoqueue)SequenceNumberSQS itself populates, andReceiveMessagereports them inAttributes, honouring the request's selection. A.fifoqueue now deduplicates as SQS does: repeating aMessageDeduplicationIdwithin 5 minutes of the accepted send succeeds and reports the originalMessageId/SequenceNumberwithout enqueueing again - but with the checksums of the request just received, since SQS digests what it was sent even when it deduplicates it away.FakeSQSgains defaulteddeduplication,queueConfigandclockconstructor parameters. - http4k-connect-amazon-dynamodb-fake: [Fix]
attribute_type(#a, :t)- the only form real DynamoDB accepts, with the type passed as an expression attribute value - now parses, resolved through the request'sExpressionAttributeValues. It previously failed to parse (escaping as a 500 onUpdateItem), so conditions written for the real service could not run against the fake. The bare-name form (attribute_type(a, S)), which the fake has always accepted and real DynamoDB rejects, still parses. - http4k-connect-amazon-dynamodb-fake: [Fix] An expression naming an undefined
#nameor:value(or a malformedattribute_typeoperand) is now reported as the 400ValidationExceptionthe real service answers with, instead of escaping as a 500 - by the conditional writes (PutItem/UpdateItem/DeleteItem/TransactWriteItems) as well asScan/Query. As at DynamoDB it is a request error, checked before the expression is evaluated, soAND/ORshort-circuiting cannot hide it - and it stays distinct from theConditionalCheckFailedExceptiona condition which resolved and came out false still produces. - http4k-connect-amazon-dynamodb-fake: [Fix]
PutItem,UpdateItem,DeleteItemandBatchWriteItemnow serialise their read-modify-write on the table storage - the monitorTransactWriteItemsalready synchronises on - so two concurrent writes to the same table can no longer both read the pre-write table and have the loser overwrite the winner. - http4k-connect-amazon-cognito: Added
AdminSetUserMFAPreferenceandSetUserMFAPreferenceactions (withSMSMfaSettingsType/SoftwareTokenMfaSettingsType/EmailMfaSettingsType/WebAuthnMfaSettingsTypemodels), so a user's MFA factors can be enabled and a preferred factor chosen. The fake supports both.