On last weeks call, there was a question in the chat if CloudEvents would expect to support thousands of extension values. I replied that I don't think it would be possible to send such an event with the HTTP Binary Content Mode, because HTTP middleware limits the headers it accepts.
I decided to follow up with some research. Most servers simply limit the total size of all HTTP headers combined. A few also limit the count of headers, or the size of a single header. Here are a few values I researched, either through documentation (linked) or through experimentation.
- AWS API Gateway: 10kb docs
- AWS ELB: 64kb total, 8kb per header docs
- Azure Functions: 64kb
- IIS: 64kb
- Google Cloud Functions: 16kb
- Google Cloud Load Balancer: 16kb
- nginx: 4kb or 8kb docs
- Apache HTTP Server: 8kb, 100 headers docs
- akka HTTP: 8kb, 64 headers docs
I'm a bit surprised that only a few HTTP servers limit the count of headers - but I guess this is good news. If we had to fit within e.g. 64 headers, and reserve space for non-CloudEvent headers as well as non-Extension headers, we'd look at 20 to 30 extensions.
However, size limitations are enforced everywhere as a DOS-protection.
We to reserve some space for normal HTTP headers (i'd guess at least 2kb, especially for Authorization headers) and regular CloudEvent properties (guessing 2kb should be fine).
8kb is widely supported, so that leaves 4kb for Extensions.
4kb is obviously just a ballpark figure, but it sounds fine to me: It is plenty of space to put data that can be used for routing, but it's - in most cases - unlikely that all of the data can be put into the extensions.
@duglin If you think this is worth presenting on the call, I can prepare a slide or two. Maybe it can also spark a discussion on similar limits in other (binary) protocols.
On last weeks call, there was a question in the chat if CloudEvents would expect to support thousands of extension values. I replied that I don't think it would be possible to send such an event with the HTTP Binary Content Mode, because HTTP middleware limits the headers it accepts.
I decided to follow up with some research. Most servers simply limit the total size of all HTTP headers combined. A few also limit the count of headers, or the size of a single header. Here are a few values I researched, either through documentation (linked) or through experimentation.
I'm a bit surprised that only a few HTTP servers limit the count of headers - but I guess this is good news. If we had to fit within e.g. 64 headers, and reserve space for non-CloudEvent headers as well as non-Extension headers, we'd look at 20 to 30 extensions.
However, size limitations are enforced everywhere as a DOS-protection.
We to reserve some space for normal HTTP headers (i'd guess at least 2kb, especially for Authorization headers) and regular CloudEvent properties (guessing 2kb should be fine).
8kb is widely supported, so that leaves 4kb for Extensions.
4kb is obviously just a ballpark figure, but it sounds fine to me: It is plenty of space to put data that can be used for routing, but it's - in most cases - unlikely that all of the
datacan be put into the extensions.@duglin If you think this is worth presenting on the call, I can prepare a slide or two. Maybe it can also spark a discussion on similar limits in other (binary) protocols.