Respect lengths and stream boundaries
04One-byte lengths bound each credential field, but TCP can deliver the request in several reads. Count bytes before interpreting application-specific text.
A partial read contains the first 16 octets of the chosen request. The final 21 byte is absent. Wait for it; then consume 17 and leave any following stream bytes intact.
Source for this drawing: RFC 1929 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The frame is 3+ULEN+PLEN octets; neither a TCP read nor a displayed character count is the field length.
- Both UNAME and PASSWD occupy 1–255 octets (§2). Thus the smallest request is 5 octets and the largest is 513. Empty fields and a 256-octet field cannot be represented by the stated format. The one-byte length is not a way to encode 256 as zero.
- For lengths 1 and 1, the chosen fictional request is 01 01 75 01 70: five octets. For 255 and 255 it is 3+255+255=513. The size comparison is schematic; a 255-octet payload is not drawn as a one-octet field.
- As a separate encoding-policy example, if two chosen username octets are C3 A9, ULEN is 02. They can represent é under UTF-8, but RFC 1929 does not mandate UTF-8, count Unicode characters, normalize identifiers or define password text processing.
- TCP is a byte stream (RFC 1928 §3 sets up the TCP connection). A partial local read is not a complete request. The teaching parser waits for all announced octets, then reports the exact consumed count and preserves following bytes; local parser validation is not a new RFC-mandated error response.
- In the 17-octet example, a read ending at offset 7 still lacks PLEN. A read ending at offset 15 still lacks the final password byte. Only after offset 16 is present can the whole request be consumed. Incomplete input is not silently padded, shortened or authenticated.
Local parser behavior is an explicit teaching policy, not a claim that RFC 1929 standardizes framing errors, timeout handling or TCP read sizes.
Read the RFC section ↗