Although there should be few problems with exceeding total byte limits as discovered in the nice research summary in #286, some servers also impose limits on the number of headers and I am not sure this was fully considered. The default limits are 100 for apache, 60 for akka, and HAProxy seems to be 101.
#364 (which might not go through) is considering this limit by specifying a maximum of 100 top-level attributes, but the HTTP transport binding in section 3.1.3.1 specifies flattening rules for binary mode metadata (introduced in #255):
Map-typed CloudEvents attributes MUST be flattened into a set of HTTP headers, where by the name of each header carries the prefix "ce-", an infix reflecting the map attribute followed by a dash ("-"), and the name of the map entry key, e.g. "ce-attrib-key".
According to #286, there should be somewhere around 4kb available for extensions, but I wonder if people might cram more than 75-80 (leaving some room for standard headers and core CloudEvents attributes) total extension attributes in that. Especially when using a property bag (a Map) in a long and noisy chain of interactions introducing bits of tracking/routing info.
If we flatten as specified currently, the top-level attribute limit in #364 would be leaky and we might limit property bag extensions when using HTTP as a transport. Somewhat confusingly, in section 3.1.3.2 the binding also specifies a mapping for JSON objects and arrays even though Map (JSON object?) is flattened and arrays are not even supported in the core spec type system, so I guess this was a guidance for extensions? Though confusing right now, it could be used as a base for switching to Map being formatted as JSON in the header value.
JSON objects and arrays are NOT surrounded with single or double quotes.
I guess my main questions here are whether this line of thinking makes sense to others and whether someone sees inherent value in flattening Maps instead of using something like JSON objects, due to e.g. compatibility or parser issues? The size impact of something like JSON compared to flattened headers should be minimal, as flattening includes its own overhead (the ce- prefix, - key separator and :<space> before value)
Although there should be few problems with exceeding total byte limits as discovered in the nice research summary in #286, some servers also impose limits on the number of headers and I am not sure this was fully considered. The default limits are 100 for apache, 60 for akka, and HAProxy seems to be 101.
#364 (which might not go through) is considering this limit by specifying a maximum of 100 top-level attributes, but the HTTP transport binding in section 3.1.3.1 specifies flattening rules for binary mode metadata (introduced in #255):
According to #286, there should be somewhere around 4kb available for extensions, but I wonder if people might cram more than 75-80 (leaving some room for standard headers and core CloudEvents attributes) total extension attributes in that. Especially when using a property bag (a
Map) in a long and noisy chain of interactions introducing bits of tracking/routing info.If we flatten as specified currently, the top-level attribute limit in #364 would be leaky and we might limit property bag extensions when using HTTP as a transport. Somewhat confusingly, in section 3.1.3.2 the binding also specifies a mapping for JSON objects and arrays even though
Map(JSON object?) is flattened and arrays are not even supported in the core spec type system, so I guess this was a guidance for extensions? Though confusing right now, it could be used as a base for switching toMapbeing formatted as JSON in the header value.I guess my main questions here are whether this line of thinking makes sense to others and whether someone sees inherent value in flattening Maps instead of using something like JSON objects, due to e.g. compatibility or parser issues? The size impact of something like JSON compared to flattened headers should be minimal, as flattening includes its own overhead (the
ce-prefix,-key separator and:<space>before value)