Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: JSON format to assume JSON content-type where possible #604

Merged
merged 1 commit into from
Feb 8, 2024

Conversation

matejvasek
Copy link
Contributor

@matejvasek matejvasek commented Jan 31, 2024

For JSON structured CE we may assume JSON datacontenttype as long as data is present int the CE.

@matejvasek
Copy link
Contributor Author

/cc @pierDipi

@@ -92,6 +92,9 @@ public <T extends CloudEventWriter<V>, V> V read(CloudEventWriterFactory<T, V> w

// Parse datacontenttype if any
String contentType = getOptionalStringNode(this.node, this.p, "datacontenttype");
if (contentType == null && this.node.has("data")) {
Copy link
Member

Choose a reason for hiding this comment

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

I think this is aligned w/ the JSON-format.md file, section 3.1:

https://github.com/cloudevents/spec/blob/main/cloudevents/formats/json-format.md#31-handling-of-data

As for the non-binary / none base64 case it states:

If the datacontenttype is unspecified, processing SHOULD proceed as if the
datacontenttype had been specified explicitly as application/json.

However the spec says should not must.

Perhaps that's part of the issue?

Choose a reason for hiding this comment

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

Yes, it can introduce dubious questioning as the one we are having in the Knative community. @duglin can you chime in?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ping @duglin

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I'm understanding the question. Is it: why is it SHOULD and not a MUST in that part of the spec? If so, I can't remember for sure, but I suspect it was done to allow for some out of band knowledge built into the event producer that allowed for it to "just know" what the real type is and take the appropriate serialization action. But w/o any extra knowledge things should assume/default to JSON. Make any sense?

Copy link
Member

@pierDipi pierDipi left a comment

Choose a reason for hiding this comment

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

Should this be done behind a configurable flag as it is a "should" vs "must" in the spec? and perhaps as opt-out?

@matejvasek
Copy link
Contributor Author

Should this be done behind a configurable flag as it is a "should" vs "must" in the spec? and perhaps as opt-out?

That may be a good idea. How would we call it? forceDatacontenttypeDefaulting forceDatacontenttypeJson ?

@matejvasek
Copy link
Contributor Author

PTAL @pierDipi @matzew

@pierDipi
Copy link
Member

pierDipi commented Feb 7, 2024

One small style nit

@matejvasek
Copy link
Contributor Author

One small style nit

fixed @pierDipi

@pierDipi pierDipi changed the title feat: assume JSON content-type where possible feat: JSON format to assume JSON content-type where possible Feb 8, 2024
Copy link
Member

@pierDipi pierDipi left a comment

Choose a reason for hiding this comment

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

Thanks @matejvasek !

LGTM

@pierDipi pierDipi merged commit 55fddb3 into cloudevents:main Feb 8, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants