From 9a9f237368098d4f893f4d5733490feeca6734df Mon Sep 17 00:00:00 2001 From: Doug Davis Date: Thu, 5 Mar 2020 11:47:49 +0000 Subject: [PATCH] mention all required attrs and shorten a bit Signed-off-by: Doug Davis --- http-protocol-binding.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/http-protocol-binding.md b/http-protocol-binding.md index 267790e61..ab70a564b 100644 --- a/http-protocol-binding.md +++ b/http-protocol-binding.md @@ -148,15 +148,14 @@ 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 -message can be a challenge. While this specification can not mandate that +being able to know when the message ought to be attempted to be parsed as a +CloudEvent 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 assumption for a receiver -to assume that if the message has the `ce-specversion` HTTP header then -it is a CloudEvent. Note, that the presence of this header does not guarantee -that the message is _binary_ instead of _structured_ since this specification -allows for _structured_ CloudEvent metadata to be copied into HTTP headers, -so the `Content-Type` header would still need to be used for that. +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 +it does not adhere to all of the normative language of this specification +then it is not a valid CloudEvent. ### 3.1. Binary Content Mode