When a features payload arrives in SSE, it uses the etag, but when an individual feature change arrives or a delete arrives, the etag is not updated to reflect this. This means that the Last-Event-ID is not useful in caching, and means the server cannot determine what the last payload the client saw was (and determine whether it needs to send anything), leading to excessive payloads.
This is especially problematic where SSE payloads cannot be compressed and are redelivered regularly to ensure the connection stays fresh causing larger than necessary bandwidth.
The problem arises because the etag is calculated in Dacha2 rather than when the features are published. It may not be efficient however to always query all the features and their values and versions every time a feature is published, that will need to be examined.
When a
featurespayload arrives in SSE, it uses the etag, but when an individual feature change arrives or a delete arrives, the etag is not updated to reflect this. This means that the Last-Event-ID is not useful in caching, and means the server cannot determine what the last payload the client saw was (and determine whether it needs to send anything), leading to excessive payloads.This is especially problematic where SSE payloads cannot be compressed and are redelivered regularly to ensure the connection stays fresh causing larger than necessary bandwidth.
The problem arises because the etag is calculated in Dacha2 rather than when the features are published. It may not be efficient however to always query all the features and their values and versions every time a feature is published, that will need to be examined.