This commit extends the `message` package to include Kafka transport.
Additionally, some of the type information has changed across the project
to more accurately reflect the type of `Message` (by including `T`).
Related: https://github.com/cloudevents/sdk-javascript/issues/390
Signed-off-by: Lance Ball <lball@redhat.com>
Adds a batched content mode for incoming events.
```js
// It's possible for this to return 1:N events
const ceArray = HTTP.toEvent(req.headers, req.body);
```
Signed-off-by: Lance Ball <lball@redhat.com>
The parser for HTTP binary made the assumption that if there was no `content-type`
header in the incoming message, it should inject `application/json`. Discussion
about the rationale for this is in https://github.com/cloudevents/sdk-javascript/issues/441.
This commit, removes that injection and adds a test to ensure the bytes are
simply not parsed, but just passed along untouched.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/441
Signed-off-by: Lance Ball <lball@redhat.com>
Even if the specversion is totally invalid, we should not change the value
received in an incoming `Message`. Previously we defaulted to 1.0 if we did
not recognize the version number. This commit changes that, leaving the value
unmodified. We default to parsing this mystery event with the 1.0 spec. When
the event is validated with `event.validate()` we return `false`.
One additional small change to eliminate a prettier warning about `parer`
being previously declared.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/332
Fixes: https://github.com/cloudevents/sdk-javascript/issues/333
Signed-off-by: Lance Ball <lball@redhat.com>
Also fixes the case where UPPERCASED extension names were silently changed
to lowercase and then set as undefined. Even though uppercased extension
names are invalid, we should still accept them in incoming messsages and
only throw when validating the event.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/380
Signed-off-by: Lance Ball <lball@redhat.com>
The `HTTP.isEvent()` and `HTTP.toEvent()` functions both had some validation
code that violated the principle of loose validation when receiving an
event over HTTP. As discussed, the validation should be managed by the
receiver in this case with `event.validate()`
Signed-off-by: Lance Ball <lball@redhat.com>
This commit extends Node.js IncomingHttpHeaders in our Headers type.
Changes the Headers type to make it more compatible with Node.js TypeScript projects.
Signed-off-by: Lance Ball <lball@redhat.com>
* fix: do not alter an event's data attribute
When setting an event's data attribute we were trying to be really clever
and this is problematic. Instead, keep the data attribute unchanged. Per
the 1.0 specification, the data attribute is still inspected to determine
if it is binary, and if so, a data_base64 attribute is added with the
contents of the data property encoded as base64.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/343
Signed-off-by: Lance Ball <lball@redhat.com>
* feat: add emitterFactory and friends
This commit adds an emitterFactory function that returns an EmitterFunction
object. The EmitterFunction may be used to emit events over a supported
network transport layer. Currently, only HTTP is supported.
Parameters provided to the emitterFactory are the transport Binding (only
HTTP supported), the encoding mode (Mode.BINARY or Mode.STRUCTURED), and
a TransportFunction.
The implementation for emitBinary and emitStructured has been replaced
with this simple pattern and those two functions have been removed.
Example:
```js
// The endpoint URL that will receive the event
const sink = 'https://my-event-sink';
// A function that uses Axios to send a message over HTTP
function axiosEmitter(message: Message, options?: Options): Promise<unknown> {
return axios.post(sink, message.body, { headers: message.headers, ...options });
}
// Create an event emitter
const emit = emitterFactory(HTTP, Mode.BINARY, axiosEmitter);
// Emit an event, sending it to the endpoint URL
emit(new CloudEvent{ source: '/example', type: 'example' });
```
Signed-off-by: Lance Ball <lball@redhat.com>
* feat: add a constructor parameter for loose validation
This commit adds a second, optional boolean parameter to the `CloudEvent`
constructor. When `false` is provided, the event constructor will not
perform validation of the event properties, values and extension names.
This commit also modifies the ValidationError class so that the error message
string includes the JSON.stringified version of any schema validation
errors. It also makes the HTTP.toEvent() function create CloudEvent
objects with loose/no validation.
Incorporates comments from https://github.com/cloudevents/sdk-javascript/pull/328
Fixes: https://github.com/cloudevents/sdk-javascript/issues/325
Signed-off-by: Lance Ball <lball@redhat.com>
Previously, the event's `time` property could be either a string or a date.
this commit modifies that to ensure that the object can only be created with
a timestamp in string format. As long as the string is a valid date, that
can be parsed by `new Date(Date.parse(str))` then whenever the event is
serialized as JSON, the `time` attribute will be formatted as per RFC 3339.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/326
Signed-off-by: Lance Ball <lball@redhat.com>
* lib(messages): Implement a 4.0 Messages and other supporting interfaces
This commit introduces the Message, Serializer and Deserializer, and Binding
interfaces used to convert a CloudEvent into a Message that can be sent across
a transport protocol. The first protocol implemented for this is HTTP, and some
of the functionality formerly in src/transport/http has been simplified,
reduced and/or moved to /src/messages/http.
Test for V1 and V3 events are in place. Conformance tests have been modified to use
these new interfaces vs. the HTTP Receiver class.
Signed-off-by: Lance Ball <lball@redhat.com>
Lance Ball
Remi Cattiau