Recover after a damaged record
03A damaged candidate need not end the sequence: a parser should continue at the next record separator.
The second candidate parses successfully. The damaged record is still lost; its position is not a reliable identifier.
Source for this drawing: RFC 7464 · Read RFC section 2.1 ↗
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
- Resynchronize
- Find the next known record boundary after damaged data.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Report a failure and resynchronize at the next RS.
- If a candidate fails UTF-8 JSON parsing, the parser SHOULD nonetheless continue with the remaining sequence. It may report the failure; the application might choose to terminate parsing.
- Multiple consecutive RS bytes do not denote empty elements and can be ignored. Sequence parsers should have an option to warn about truncated JSON texts.
- Missing or truncated records make position-based references unreliable. The format does not guarantee a reliable nth element, delivery, recovery of missing data or an end-of-sequence signal.
This example policy warns, skips a malformed {"n": candidate, ignores an extra consecutive RS, then accepts {"n":2}. Recovery is the recommended parser behavior, not a promise that every application must continue or that the broken record is reconstructed.
Read the RFC section ↗