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>
It has been nearly two years since 1.0 became final. This change removes
support for 0.3 events in the interest of simplifying the project a little.
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>
* src: be more forgiving parsing JSON as a string
A simple string is considered valid JSON. However, our parsers do
not accept that unless the string has quotation marks. This commit
modifies the parser to look for strings declared as application/json
which do not begin with '[' '{' or '"' and surrounds them with
quotes.
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>
* feat!: remove all 4.0 deprecation.
* This removes all the APIs that were deprecated in the 3.x releases and marked as "remove in 4.0".
* Also removes any tests associated with those API's
* squash: remove axios as a dependecy
Signed-off-by: Lucas Holmquist <lholmqui@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>
This commit implements 4 of the 6 pending tests that were not completed
during the TypeScript rewrite. The two tests that were not implemented
were (one for each of v1 and v03):
```
it("returns a JSON string even if format is invalid");
```
I don't really know what that's supposed to be/mean, so I removed them.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/232
Signed-off-by: Lance Ball <lball@redhat.com>
* Constants can now be accessed more easily from the top level import/require
users can now do `const { CONSTANTS } = require('cloudevents')`
fixes#298
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
The schema incorrectly limits data values to only object and string. This is
incorrect, since JSON can be an array, boolean, a single number or null as well.
This commit modifies the schema to allow for array, boolean and null, and adds
tests.
Fixes: https://github.com/cloudevents/sdk-javascript/issues/280
Signed-off-by: Lance Ball <lball@redhat.com>
This commit modifies the HTTP receivers/parsers to allow for the incoming body
of an HTTP request to be empty if the event message is sent using the binary
mode. In structured mode, a `ValidationError` will still be thrown, since the
entire event must be encoded in the HTTP body.
Signed-off-by: Lance Ball <lball@redhat.com>
BREAKING CHANGE:
* Extension names are now validated during object creation. The values are defined by the specification, and can be lowercase(a-z) or digits(0-9) and must be no longer that 20 characters
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
BREAKING CHANGE:
* This change makes the CloudEvent Read-only and validates the input during object creation.
* To augment an already created CloudEvent object, we have added a `cloneWith` method that takes attributes to add/update.
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>