Repository navigation
SHOULD throw if ce-datacontenttype is present in binary mode? #381
Description
Describe the Bug
Spec states that the ce-datacontenttype header MUST NOT be present in a binary mode message. If it is passed anyway, no error is thrown and the given ce-datacontenttype is treated as extension attribute overwriting the value from the Content-Type header.
Steps to Reproduce
Use the following snippet:
const event = HTTP.toEvent({
headers: {
'Content-Type': 'application/json',
'ce-id': '0815',
'ce-specversion': '1.0',
'ce-type': 'my.event.type',
'ce-source': 'my.event.source',
'ce-datacontenttype': 'text/xml',
},
body: {}
})Check the resulting event:
{
//...
id: '0815',
specversion: '1.0',
type: 'my.event.type',
source: 'my.event.source',
datacontenttype: 'text/xml'
}Expected Behavior
HTTP.toEvent should throw to prevent this.
Additional context
Not quite sure why the datacontenttype (also without ce- prefix) is part of the binary parsers so maybe it is intentional though?
And I assume this is also a bug (where it should use v03binaryParsers on the else path instead):
sdk-javascript/src/message/http/index.ts
Line 141 in 6be3b27
Activity
lance commentedon Mar 5, 2021
I don't think it should, to be honest. This is similar to other scenarios that have been pointed out with regard to receiving malformed events. The
HTTP.toEvent()function is meant to be used when receiving events via incoming HTTP requests, and we should be as forgiving as possible. To me the debate is really, what should thedatacontenttypevalue be in this scenario,text/xmlorapplication/json?Thanks for pointing out those two bugs. You're right that they are incorrect.
github-actions commentedon Apr 5, 2021
This issue is stale because it has been open 30 days with no activity.