How can `Content-Encoding: gzip` on a Server-Sent Events response defeat incremental delivery, and which directive pushes back?

## Two places the coding can come from When a bottling-line feed arrives compressed, there are two candidate sources and they have different fixes: 1. **The origin applied it.** A server framework that compresses responses by content type may compress `text/event-stream` along with everything else, because a text media type looks like an obvious win. 2. **An intermediary applied it.** A transforming intermediary is entitled to apply a content coding the origin never set, choosing it from the codings the client advertised in the request's `Accept-Encoding` field. `Content-Encoding` is the response field naming what was applied; `Accept-Encoding` is the request field naming what the client will accept. Mixing those two up is the most common slip in this answer. The second case is the one that surprises people, because the origin's own configuration shows no compression anywhere and the response on the wire is compressed regardless. ## Why compression eats a live feed A compressor works over a window of input. To choose good encodings it wants input, and the cheapest implementation strategy is to accumulate until it has a block worth of bytes and only then emit compressed output. On a feed of short events -- a line number, a speed, a jam flag -- a block is many events wide, so the first twenty events produce **no output at all**, then all twenty appear together. The important nuance, and the one that keeps this claim honest: a compressor **can** be told to flush at a chosen point, emitting whatever it has so far and paying for it in ratio, and stacks that support streaming compression do exactly that. So compression does not necessarily destroy incremental delivery. What destroys it is a compressor whose flush policy is chosen for whole documents applied to a response that is not one. There is a second cost even when flushing is correct: a compressing intermediary has to read, decode and re-encode the body, which means it is handling the body rather than passing it through -- so it is a buffering intermediary too, with all of the behaviour that implies. ## The lever, and its limits `Cache-Control: no-transform` is the standard directive for this. It tells intermediaries on the path that they must not change the payload -- specifically not its content coding or its media type. Put it on every streamed response; it costs one token and it is the only standard way to say "leave this body exactly as it is". Its limits are worth stating plainly: - It addresses **transformation**, not accumulation. An intermediary that honours `no-transform` and still buffers the untouched body produces the same clumping. - It is a directive, and an intermediary that ignores directives ignores this one. - It does nothing about compression the **origin** applied, which is yours to turn off. ## Deciding what the origin should do | Setting | Effect on a live feed | When it is right | |---|---|---| | No content coding on the stream | Each event is forwarded as written | The default choice; event payloads are small and the ratio is not worth the risk | | Streaming compression, flushed per event | Incremental delivery preserved, ratio reduced | Large event payloads over constrained links, when the stack genuinely supports per-event flushing | | Block-buffered compression | Incremental delivery destroyed | Never on a response that is meant to arrive as it is produced | For most feeds the first row wins. The events are short, the saving is small, and the failure mode is invisible until it reaches production. ## How to diagnose it 1. Read the response header fields as they arrive at the receiver, not as the origin configured them. If `Content-Encoding` is present and the origin never set it, a transforming intermediary added it. 2. Request the same path with no compression offered in the request. If the feed becomes smooth, the coding was the cause rather than a separate buffering hop. 3. If it is still clumpy without any coding, you are looking at plain response buffering instead, and compression was a red herring. ## Why interviewers like this one It catches two habits at once. The first is assuming that everything on the wire was put there by your code -- the response you configured is not necessarily the response that arrives. The second is treating compression as a pure win, which it is on documents and is not on anything that must arrive as it is produced. A candidate who reaches for `no-transform` and then immediately says "but it does not stop buffering" has the whole shape of this leaf.