-
Notifications
You must be signed in to change notification settings - Fork 160
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
Conversation
/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")) { |
There was a problem hiding this comment.
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 asapplication/json
.
However the spec says should not must.
Perhaps that's part of the issue?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ping @duglin
There was a problem hiding this comment.
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?
There was a problem hiding this 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?
That may be a good idea. How would we call it? |
8a58df9
to
a2bb831
Compare
formats/json-jackson/src/main/java/io/cloudevents/jackson/JsonFormatOptions.java
Outdated
Show resolved
Hide resolved
One small style nit |
Signed-off-by: Matej Vašek <[email protected]>
7c37753
to
df80e19
Compare
fixed @pierDipi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @matejvasek !
LGTM
For JSON structured CE we may assume JSON
datacontenttype
as long asdata
is present int the CE.