The question

An upstream promises 100 bytes, sends 40, and closes. Why can a cache still publish the short file even when the first client reports an incomplete response?

Working model

Some HTTP read APIs return an ordinary empty read at premature EOF. The downstream client notices that the forwarded Content-Length was not met, but the proxy's loop may interpret EOF as success.

When an upstream declares a nonnegative length, count the bytes written and compare the count before publication. On mismatch, fail the fill and let temporary-file cleanup remove the candidate. A later request can then reach the upstream again.

Atomic rename and length validation compose: either one alone can still publish the wrong state.

Provenance

Synthesized from a Python http.client / mmdebstrap investigation at Linux Fieldwork revision c79d34b65fb2cd8c54234f361f073248c53b513a.

Diagnose it

For each case, decide whether EOF is enough to publish:

1. Content-Length: 100, received 100.
2. Content-Length: 100, received 40.
3. No declared length, response is validly close-delimited.

Then explain why “the first client already failed” does not protect the next client from a poisoned cache.