Skip to content

fix: do not alter an event's data attribute - #344

Merged
lance merged 4 commits into
cloudevents:mainfrom
lance:343-dont-always-encode-event-data
Oct 6, 2020
Merged

lance merged 4 commits into
cloudevents:mainfrom
lance:343-dont-always-encode-event-data

Conversation

@lance

@lance lance commented Sep 28, 2020

Copy link
Copy Markdown
Member

Proposed Changes

  • Change CloudEvent so that it never modifies the data attribute
  • If an event's datacontenttype property is a content type that we don't support, just set the data attribute - don't throw

Description

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 data, and if so, a data_base64 attribute is added with the contents of the data property encoded as base64.

Fixes: #343

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

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: cloudevents#343

Signed-off-by: Lance Ball <lball@redhat.com>
@lance lance added module/transport/http Issues related to the HTTP transport protocol implementation type/fix A change that fixes something that is broken version/4.x Issues related to the 4.0 release of this library labels Sep 28, 2020
@lance
lance requested a review from a team September 28, 2020 20:41
@lance lance self-assigned this Sep 28, 2020
@lance
lance marked this pull request as draft September 29, 2020 21:40
@lance

lance commented Sep 29, 2020 •

Copy link
Copy Markdown
Member Author

Do not merge. I have found a bug in this implementation that I need to fix. Per the spec, this test is incorrect.

The spec reads:

When a CloudEvents is deserialized from JSON, the presence of the data_base64 member clearly indicates that the value is a Base64 encoded binary data, which the serializer MUST decode into a binary runtime data type.

// Instead of this
      expect(eventDeserialized.data).to.equal({ foo: "bar" });
// It should be
      expect(eventDeserialized.data).to.equal(dataBinary);

@lance

lance commented Sep 30, 2020

Copy link
Copy Markdown
Member Author

@cloudevents/sdk-javascript-maintainers there is an interesting discussion in Slack around this question of binary data: https://cloud-native.slack.com/archives/C9DB5ABAA/p1601416717013400

Unless... its datacontenttype is application/json. In that case it
should be converted into an object.

Signed-off-by: Lance Ball <lball@redhat.com>
Signed-off-by: Lance Ball <lball@redhat.com>
@lance
lance marked this pull request as ready for review September 30, 2020 21:43
@lance

lance commented Sep 30, 2020

Copy link
Copy Markdown
Member Author

@cloudevents/sdk-javascript-maintainers PTAL - thanks

@grant grant left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not modifying the data is great.
I think we'll talk about base64 data a bit more in the weekly SDK call too.

@lance

lance commented Oct 1, 2020 •

Copy link
Copy Markdown
Member Author

Based on the discussion in today's CNCF call, I am going to remove this test and the associated functionality.

it("Parses binary data from binary messages with content type application/json", () => {
const message = HTTP.binary(fixture.cloneWith({ data: dataBinary }));
const eventDeserialized = HTTP.toEvent(message);
expect(eventDeserialized.data).to.deep.equal({ foo: "bar" });
expect(eventDeserialized.data_base64).to.be.undefined;
});

Edit: I did not remove the test. Instead, I changed it to assert that we do NOT parse binary data even if the datacontenttype is application/json.

Signed-off-by: Lance Ball <lball@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module/transport/http Issues related to the HTTP transport protocol implementation type/fix A change that fixes something that is broken version/4.x Issues related to the 4.0 release of this library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Binary data in binary format is not binary?

3 participants