How to determine binary CE vs random non-CE message #577
Conversation
| message can be a challenge. While this specification can not mandate that | ||
| senders do not include any of the CloudEvents HTTP headers when the message | ||
| is not a CloudEvent, it would be a reasonable for a receiver to assume that if | ||
| the message has all of the mandatory CloudEvents attributes as HTTP headers |
There was a problem hiding this comment.
What if it doesn't have all of the mandatory attributes? Should be considered non-event or not valid event? Maybe is it more convenient to state: if a request has the spec version attribute, then it should be handled as event (even not valid one)
There was a problem hiding this comment.
If the incoming message doesn't have all (4) required attributes then it is not a valid CE. While SDKs might choose to treat it as a CE but flag it as "incomplete", that is there choice. But from a spec perspective I don't think we can say anything other than all 4 are required to be a CE, anything else isn't a CE.
http-protocol-binding.md
Outdated
| @@ -147,6 +147,14 @@ If a receiver detects the CloudEvents media type, but with an event format that | |||
| it cannot handle, for instance `application/cloudevents+avro`, it MAY still | |||
| treat the event as binary and forward it to another party as-is. | |||
|
|
|||
| When the `Content-Type` header is not prefixed with the CloudEvents media type, | |||
| being able to distinguish between a _binary_ CloudEvent and a non-CloudEvent | |||
There was a problem hiding this comment.
So maybe the word "distinguish", at least to me, is unclear. With distinguish do you mean "start the parsing, even of a non valid event" or "start the parsing of a valid event?".
If I understood the goal here, you want to give an hint to the spec implementer on how to implement the parsing process of the HTTP envelope. If that's the case, I think it would be useful to specify that if it has the specversion, then it's an event, potentially non valid
There was a problem hiding this comment.
See comment below, from a spec perspective, if an incoming CE doesn't adhere to all of the MUSTs in the spec then it is not a valid CE. What a receiver chooses to do with it at that point is an impl choice - the spec is silent on that because we purposely decided not to get into the processing model side of things (for the most part).
So, I guess "distinguish" can be interpreted as "whether someone should try to parse it as a CE" yes, but even then there's no guarantee that it'll pass all of the MUST checks. I've added a little of of rewording - see what you think.
There was a problem hiding this comment.
I like the rewording, thanks!
http-protocol-binding.md
Outdated
| senders do not include any of the CloudEvents HTTP headers when the message | ||
| is not a CloudEvent, it would be a reasonable for a receiver to assume that if | ||
| the message has all of the mandatory CloudEvents attributes as HTTP headers | ||
| then it probably a CloudEvent. However, as with all CloudEvent messages, if |
|
on 3/12 call, there was agreement with the overall direction - so next step is to modify the other transport specs appropriately. |
duglin
force-pushed
the
whenCE
branch
2 times, most recently
from
f649e6b to
06fcf63
Compare
Add some guidance for how to determine when an incoming message is a binary CE vs some random non-CE message. The same receiver might accept CE and non-CE messages so we should have an interoperable way for them to know what they're getting Signed-off-by: Doug Davis <dug@us.ibm.com>
|
Updated all transport specs except nats. PTAL |
|
Approved on the 3/26 call. |
Add some guidance for how to determine when an incoming message is a binary
CE vs some random non-CE message. The same receiver might accept CE and non-CE
messages so we should have an interoperable way for them to know what they're
getting.
If people are ok with this general direction then I can make the same change to the other transport specs.
Signed-off-by: Doug Davis dug@us.ibm.com