Commit Graph

4 Commits

Author SHA1 Message Date
Lance Ball 09b0c76826
feat: add ValidationError type extending TypeError (#151)
This change adds a `ValidationError` type that extends `TypeError`. Any time a `CloudEvent` cannot be received and created with the given input, this error will be thrown. Tests have all
been updated to check for the error type.

Signed-off-by: Lance Ball <lball@redhat.com>
2020-05-13 13:27:18 -04:00
Lance Ball ef7550d60d
fix: throw "no cloud event detected" if one can't be read (#139)
This commit changes the event mode detection in `HTTPReceiver` so that it will
throw a TypeError if the event mode can't be detected per the spec.

Signed-off-by: Lance Ball <lball@redhat.com>
2020-05-11 09:42:16 -04:00
Lance Ball 72a87dfb2d
fix: ensure binary events can handle no content-type header (#134)
* fix: ensure binary events can handle no content-type header

The fix provided in https://github.com/cloudevents/sdk-javascript/pull/118
only included tests for `receiver.check()`, and the change in that
case was to add the `application/json` content type to the cleansed
headers if to type was specified.

However, `receiver.parse()` did not receive the benefit of this change. It
calls `this.check()` but then sanitizes the original headers again, and the
missing content-type was not re-inserted into the newly sanitized headers.

This commit, modifies the code so that `receiver.check()` does not insert
the content-type, but does allow the validation check to pass if no
content-type header exists. When `receiver.parse()` is called, and the
headers are sanitized again - and this time used to look up parser implementation,
the default `application/json` content-is applied if no content-type header
exists.

I've also removed a redundant call to `receiver.check()` in receiver_binary_1.js
and simplified the usage of `Constants` in the test.

Signed-off-by: Lance Ball <lball@redhat.com>

* chore: clean up header sniffing

Signed-off-by: Lance Ball <lball@redhat.com>
2020-05-08 23:37:10 -04:00
Lance Ball 54f242b79e
feat: expose a mode and version agnostic event receiver (#120)
Event receivers in the wild may not always know what version or mode an
incoming event is. Instead of requiring developers to inspect the headers
themselves, the SDK should provide an HTTP receiver that is capable of
figuring out what the version and mode (structured/binary) of an incoming
event is and handle it appropriately.

In determining the best way to expose this, I chose to modify the API a
little bit. Now, instead of `const CloudEvent = require('cloudevents-sdk');`
users need to destructure it.

```js
const { HTTPReceiver, CloudEvent } = require('cloudevents-sdk');
```

This change should not be backported to 1.x.

Fixes: https://github.com/cloudevents/sdk-javascript/issues/93

Signed-off-by: Lance Ball <lball@redhat.com>
2020-05-06 13:25:16 -04:00