Harmonize validation of CloudEvents

[manuelottlik]

Is your feature request related to a problem? Please describe. My problem is related to the validation of extensions. While new CloudEvent() rightfully rejects an extension named my-extension (problem being the -) it is perfectly okay for HTTP.toEvent() and even to ce.validate().

Describe the solution you would like to see I think the creation of a CE should always have the same validations in place, no matter if its created by new CloudEvent() or via HTTP.toEvent(). I also think the validate() method should consider extensions.

Additional context I transport my CEs via HTTP and therefore have a service that takes an HTTP request with HTTP.toEvent(), validates the CE with ce.validate() and then puts it in my event broker. On the consuming side there is a service that takes the event from the broker, creates a new CloudEvent with new CloudEvent() and sends it via axios using the HTTP.binary() function.

[manuelottlik]

To anyone running into this issue, this is my fix for the moment:

evt = new CloudEvent(HTTP.toEvent({ headers: req.headers, body: req.body }));

[lance]

@manuelottlik we explicitly require incoming events to be manually validated, where extensions with non-conformant names should result in an error. See this test: https://github.com/cloudevents/sdk-javascript/blob/ea94a4d779d0744ef40abc81d08ab8b7e93e9133/test/integration/message_test.ts#L43-L57

The reason for this is that you cannot know what the incoming event might look like, and this gives the receiver the opportunity to accept invalid events if desired. Our motto is be loose in what we accept, but strict in what we create.

If I am somehow missing your point, could you please provide some code that reproduces the problem you are seeing specifically? Thanks!

[manuelottlik]

Hi @lance, thank you for pointing that out – this makes sense to me regarding HTTP.toEvent(), but the behaviour ce.validate() is really confusing in my opinion. It returns true but its actually not valid.

[lance]

Hi @lance, thank you for pointing that out – this makes sense to me regarding HTTP.toEvent(), but the behaviour ce.validate() is really confusing in my opinion. It returns true but its actually not valid.

@manuelottlik sorry I have not seen that behavior. In our tests, we have expect(() => evt.validate()).to.throw(TypeError); which should be the case for invalid extension attribute names. I agree that the API is weird - it will return true if valid and throw otherwise. But you still should be seeing an exception. Can you provide me with some code that duplicates the issue you are seeing?

[manuelottlik]

I will check, but might need a few days.

[lance]

@manuelottlik just checkin in on this. Have you had a chance to validate?

[manuelottlik]

Hey @lance, I am currently traveling, I am not sure when I will be able trying to reproduce this, sorry. But will definitely do!

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity.

[manuelottlik]

Hey @lance, sorry for the long wait. I was able to validate your code – not sure what I did wrong there in the past, it is working as expected. Sorry!