While reviewing the current NATS protocol binding (1.0.3-wip), I noticed a possible ambiguity in structured-mode detection:
Section 3 of the NATS binding states:
If the server is version 2.2 or above and the Content-Type header of application/cloudevents is present (matched case-insensitively), then the message is in structured mode, otherwise it is using binary mode.
However, Section 3 of the JSON event format states:
Such a representation MUST use the media type application/cloudevents+json.
With an exact comparison, a message carrying Content-Type: application/cloudevents+json would therefore be classified as binary rather than structured.
The HTTP binding explicitly describes application/cloudevents as a prefix for mode detection.
Since I imagine the NATS binding's intent is to have a prefix (like the HTTP binding), I suggest changing the wording to reflect that.
Links
The NATS detection rule was introduced in PR #1016. The JSON format already required application/cloudevents+json before that change.
While reviewing the current NATS protocol binding (
1.0.3-wip), I noticed a possible ambiguity in structured-mode detection:Section 3 of the NATS binding states:
However, Section 3 of the JSON event format states:
With an exact comparison, a message carrying
Content-Type: application/cloudevents+jsonwould therefore be classified as binary rather than structured.The HTTP binding explicitly describes
application/cloudeventsas a prefix for mode detection.Since I imagine the NATS binding's intent is to have a prefix (like the HTTP binding), I suggest changing the wording to reflect that.
Links
The NATS detection rule was introduced in PR #1016. The JSON format already required
application/cloudevents+jsonbefore that change.