Resource limits and terminal parser errors
What this concept is
A length field is untrusted input. The parser accepts payloads only through 1024 bytes and rejects oversize declarations as soon as the header completes. Terminal errors prevent later data from being interpreted under an already-broken stream state.
Why it matters here
Allocating the declared length before validation allows a tiny header to request enormous storage. A payload bound alone also does not bound the number of queued messages or connections. Different resources need separate limits.
Concrete example
Header 00 00 04 01 declares 1025 and fails without a body. Header 00 00 04 00 declares 1024 and is valid. A chunk containing a valid ok frame then an oversize header returns the completed ok message together with oversize; earlier delivery is not rolled back.
Common confusion / misconception
A parser buffer bound is not a bound on total application heap. Caller chunks, returned objects and queues also consume memory. Even empty frames allocate output objects. Likewise, framing does not authenticate the sender or validate the meaning of a payload.
How to use it
Define the limit inclusively, specify zero-length behavior, and make terminal errors sticky. On EOF, accept only a frame boundary; a partial header or body is truncation. Close the connection after protocol failure rather than guessing a new boundary in arbitrary bytes.
Check yourself
Can a complete frame before a bad frame already have caused a side effect? Yes. If atomic handling of a batch is required, where must that guarantee live? In a separate application transaction, not an assumed parser rollback.
Mini drill or application
Test lengths 0,1,1024,1025 and the largest four-byte unsigned integer. Inject EOF at every offset of a maximum frame. Explain which two EOF positions are clean for a single frame: before any bytes, and after all bytes.
Read this only if stuck
Use Computer Networking protocol foundations to separate syntax, resource policy and application semantics.