pub enum PayloadPermission {
Permitted,
Forbidden,
}Expand description
Whether an object carrying a given status may hold a non-empty payload.
Section 10.2.1.1 states the rule in one sentence — “Any object with a
status code other than zero MUST have an empty payload” — so on this draft
the answer falls out of the code being zero or not, and every status but
ObjectStatus::Normal forbids a payload.
It is worth a type all the same, because that arithmetic is not something a
consumer can safely perform on a raw wire code. A code this draft does not
assign is not non-zero, and therefore forbidden: it is a code with no
meaning at all, and no payload rule attaches to it. Handing back a
PayloadPermission keeps the two apart, and lets a caller ask the question
without restating the rule — or, worse, restating it slightly differently.
Variants§
Permitted
The status permits a payload but does not require one: a zero-length object with such a status is well formed, and this draft’s encodings have a way to spell it.
Forbidden
An object with such a status has an empty payload, and one carrying bytes is malformed.
Implementations§
Source§impl PayloadPermission
impl PayloadPermission
Sourcepub fn for_status(status: ObjectStatus) -> Self
pub fn for_status(status: ObjectStatus) -> Self
The permission this draft gives objects carrying status.
Written as a match over every assigned status rather than as a test for
zero, so that a status added to ObjectStatus later cannot quietly
inherit not Normal, therefore forbidden — it stops the crate
compiling until its own answer is written down.
Sourcepub fn permits(self) -> bool
pub fn permits(self) -> bool
true for PayloadPermission::Permitted.
The permission answers on its own, with no payload length in hand, which is the point of asking the status rather than the framing.