CloudEvent with no datacontenttype parsed as JSON instead of plain text

[csantanapr]

Describe the Bug
Doing a demo based on this blog to consume S3 events from Kamelet
The nodejs SDK can't handle the HTTP POST request with cloud event
Using the following code https://github.com/knative/docs/blob/main/docs/serving/samples/cloudevents/cloudevents-nodejs/index.js

Steps to Reproduce

1. create nodejs service
2. create trigger to send cloudevent from broker to nodejs service

Expected Behavior
That the cloud event is properly handle.
The knative event-display using the goland cloudevent can handle plaintext in body and missing content-type in header.
https://github.com/knative/eventing/blob/main/cmd/event_display/main.go#L59

Additional context

Try both versions of the SDK 4.0.3 and 5.0.0 same error

The input event from Camel Kamelet S3 is the following

Debug Incoming Request: {
   "headers": {
     "host": "func1.default.svc.cluster.local",
     "user-agent": "Go-http-client/1.1",
     "content-length": "11",
     "accept-encoding": "gzip",
     "ce-id": "A8A6BD24B2AE5FF-0000000000000017",
     "ce-knativearrivaltime": "2021-11-17T22:48:50.315578709Z",
     "ce-source": "source",
     "ce-specversion": "1.0",
     "ce-time": "2021-11-17T22:48:50.306Z",
     "ce-type": "org.apache.camel.event",
     "forwarded": "for=10.131.0.156;proto=http",
     "k-proxy-request": "activator",
     "traceparent": "00-0f3421c775056be4f762f87b5cee145d-5f24409ef4edc327-00",
     "x-forwarded-for": "10.131.0.156, 10.128.2.48",
     "x-forwarded-proto": "http",
     "x-request-id": "13396d30-5487-46c1-9d21-b3fd675447e0"
   },
   "body": "test func1\n"
 }

The error is the following

SyntaxError: Unexpected token 
  in JSON at position 11
     at JSON.parse (<anonymous>)
     at parseJSON (/opt/app-root/src/node_modules/cloudevents/dist/parsers.js:39:67)
     at JSONParser.parse (/opt/app-root/src/node_modules/cloudevents/dist/parsers.js:40:16)
     at parseBinary (/opt/app-root/src/node_modules/cloudevents/dist/message/http/index.js:166:23)
     at Object.deserialize [as toEvent] (/opt/app-root/src/node_modules/cloudevents/dist/message/http/index.js:86:20)
     at /opt/app-root/src/index.js:70:24
     at Layer.handle [as handle_request] (/opt/app-root/src/node_modules/express/lib/router/layer.js:95:5)
     at next (/opt/app-root/src/node_modules/express/lib/router/route.js:137:13)
     at Route.dispatch (/opt/app-root/src/node_modules/express/lib/router/route.js:112:3)
     at Layer.handle [as handle_request] (/opt/app-root/src/node_modules/express/lib/router/layer.js:95:5)

cc @lance

[lance]

@csantanapr you are right to point out that the SDK should be able to handle this event. I will note, however, that the event itself is not valid - at least not as represented in the HTTP protocol format.

From the spec we find this about the datacontenttype property:

For some binary mode protocol bindings, this field is directly mapped to the respective protocol's content-type metadata property. Normative rules for the binary mode and the content-type metadata mapping can be found in the respective protocol

Which is basically saying, check the HTTP transport spec. Which states:

In the binary content mode, the value of the event data is placed into the HTTP request, or response, body as-is, with the datacontenttype attribute value declaring its media type in the HTTP Content-Type header; all other event attributes are mapped to HTTP headers.

In this case, the event has neither a datacontenttype attribute nor a content-type header. So, what's an SDK expected to do? We can guess, I suppose. But if we go back to the spec for guidance, the next paragraph after the one quoted above says this:

In some event formats the datacontenttype attribute MAY be omitted. For example, if a JSON format event has no datacontenttype attribute, then it is implied that the data is a JSON value conforming to the "application/json" media type. In other words: a JSON-format event with no datacontenttype is exactly equivalent to one with datacontenttype="application/json".

Which leads me to believe that the Node.js SDK is actually doing things correctly, and interpreting the incoming event as application/json. TBH, I'm not sure exactly what should happen here, as it's not very clear. I'd be interested in seeing the golang logic for figuring out what to do in this case. Are you familiar with that SDK?

[csantanapr]

@n3wscott should know what the golangsdk does in this case and able to handle it correctly.

[csantanapr]

In the mean time should we also open an issue for kamelete s3 source for not including a content type plain/text?

I'm not you even where to open the issue. I just used openshift and installed the Camel operator

[duglin]

Seems to me that the SDK should not be parsing the body at all - it's binary and should be passed on to the app as an array of bytes. If there was a content-type header that says it is JSON, then the SDK might try to be smart and convert it to a JSON object, but w/o that it seems like the SDK has no choice but to treat it as an array of bytes, not JSON.

[duglin]

TBH I can even see an argument to be made that if the content-type was JSON but the body had invalid JSON, then the SDK should still pass it along to the app 'as is'. It all depends on whether the SDK is supposed to be a pass-thru or a validator. Depending on the usecase, either might be right. A flag to control this type of thing (perhaps exposed as "always pass event as raw bytes") might be useful.

[lance]

Seems to me that the SDK should not be parsing the body at all - it's binary and should be passed on to the app as an array of bytes.

I'll be willing to bet this is what the Go SDK is doing.