Skip to main content

extensions_permitted_at

Function extensions_permitted_at 

Source
fn extensions_permitted_at(status: Option<u64>, extensions_len: u64) -> bool
Expand description

Whether an Object at status is allowed to carry extensions_len bytes of extension headers.

Draft-16 Section 10.2.1.2: “Any Object with status Normal can have extension headers”, with a reference to Section 2.5 inside the sentence, and “If an endpoint receives extension headers on Objects with status that is not Normal, it MUST close the session with a PROTOCOL_VIOLATION.”

Draft-16 is the draft where the status set narrowed to Normal, End of Group and End of Track, so the rule reaches two codes rather than the single “Object Does Not Exist” earlier drafts name, draft-15 Section 10.2.1.1 among them. It reaches every carrier that can announce a status: an Object on a subgroup stream and a status datagram. An Object on a fetch stream carries no status field on this draft — Section 10.2.1.1 puts the field on subscription deliveries only — so it is the one carrier that cannot break the rule.

So this is false for exactly one shape: a non-empty extension block on an Object whose status is not Normal. An Object with no extensions is fine at any status, and an Object at Normal may carry any extensions.

status is taken as a raw code so the two subgroup readers can share this: one resolves the status into ObjectStatus and the other keeps the wire code. None means the Object carried a payload, which is Normal by definition and always permitted.

§Why the readers do not apply this themselves

A deliberate contrast with the payload rule beside it. A status next to a payload has no encoding — the status field and the payload occupy the same position on the wire — so a writer refuses that pair as unrepresentable. Extensions next to a status encode perfectly well: the block sits between the extensions length and the status field and reads back byte for byte. The frame is well formed and merely non-conforming, which is a judgement about what a peer may send, not about what the bytes mean.

A decoder that refused it could not report the violation, and a writer that refused it could not reproduce a capture containing one — including the committed subgroup-extensions-status-object vector, which is exactly this frame. The rule addresses an endpoint receiving such an Object, so the endpoint is where it is enforced. This predicate is what it asks.