Your text/event-stream feed emits a line with no colon and a field name the grammar never defines - how does a conforming client treat each?

Streams in production are rarely clean. A feed may be produced by a much older system, re-emitted by a component nobody owns, or extended by a team that added a line of its own. The specification anticipates this: the parsing rules are written so that a client can meet input the grammar does not define and keep going. Knowing exactly which input is survivable is what separates someone who has read the rules from someone who has only used a client library. ## Tolerance is a rule, not a courtesy There is no fatal parse error in the body of an event stream. Whatever arrives, the client keeps reading and keeps dispatching whatever it could build. The three cases worth knowing: - **A non-empty line with no `U+003A COLON (:)`** - the whole line is processed as a field name, with the empty string as the field value. A line reading `data` behaves as `data:` with nothing after it. - **A field name the grammar does not define** - the field is ignored. `severity: minor` contributes nothing at all; it is not passed through, not exposed to the receiving application, and not an error. - **A leading `U+FEFF BYTE ORDER MARK`** - the `UTF-8` decode removes exactly one, and only at the very start of the stream. A mark appearing later is ordinary text: it becomes the first character of whatever field name follows it, which is then unrecognised and ignored. | input the client meets | what it does | what it never does | |---|---|---| | non-empty line, no colon | whole line is the field name, value is empty | discard the line, or end the stream | | unrecognised field name | ignores field and value | pass it to the receiving application | | one leading byte order mark | strips it during decode | strip a second one later | | a later byte order mark | leaves it in the text | report an encoding error | ## Why the specification chose this Two reasons, and both matter operationally. First, **forward compatibility**: because unknown fields are ignored rather than rejected, a server may emit a field that older clients have never heard of without breaking any of them. The extension point is free, and it is the ignore rule that pays for it. Second, **an unattended client**: the receiving side reconnects by itself and often runs for days with nobody watching it. A client that treated a stray line as fatal would take an entire fleet down over a formatting slip in one event. ## The cost of that generosity Silence cuts both ways. Because nothing complains, a mistake on the emitting side can run for months: - a misspelled field name - `date:` where `data:` was meant - is dropped without a sound, and the event arrives missing whatever that line carried; - a line intended as a comment but written without its leading colon becomes a field name with an empty value instead of being skipped; - a system that concatenates two streams may put a byte order mark in the middle of the combined output, where it silently corrupts the field name that follows it. None of these produces an error anywhere. The client is behaving exactly as specified, the receiving application sees an event that is merely incomplete, and the only place the defect is visible is in the bytes on the wire. ## What to do about it The check has to live on the side that emits, because the side that receives will never raise one. 1. Build the stream with one function that writes fields, rather than by string-concatenating lines at call sites. Field names then cannot be misspelled per call site. 2. Assert on the wire in tests: capture the raw response body of a streaming endpoint and compare bytes, including the blank line that ends each event. A test that asserts on parsed objects cannot see a field that was ignored. 3. When you bridge a feed from an upstream system whose output you do not control, validate it at the bridge and record what you dropped. Anything you pass through unexamined, the client will silently ignore for you. 4. Treat a byte order mark as a hazard whenever streams are produced by concatenation or by a tool that writes one by default. Exactly one, at the very start, is invisible; anywhere else it is corruption you will not be told about. The rule to carry out of this: the tolerance rules protect availability, not correctness. They guarantee a malformed line will not take the stream down. They guarantee nothing at all about the event arriving intact.