fix(conformance): allow optional space after SSE data: field name#285
fix(conformance): allow optional space after SSE data: field name#285ethe wants to merge 1 commit into
Conversation
The SSE specification (W3C Server-Sent Events) defines the data field
format as `data:VALUE` where if the first character after the colon is
a U+0020 SPACE, it is stripped. This means both `data:hello` and
`data: hello` are valid and produce the same value.
Several conformance test regexes used `data:({...})` which only matches
the no-space variant. This causes false failures against servers that
use `data: ` (with space), such as implementations built on Axum, Actix,
or other frameworks that follow the common convention of including a
space after the colon for readability.
Change all SSE data field regexes from `data:` to `data: ?` (optional
space) and text assertions from `toContain("data:line")` to
`toMatch(/data: ?line/)`.
Reference: https://html.spec.whatwg.org/multipage/server-sent-events.html#event-stream-interpretation
✅ Deploy Preview for durable-streams-docs canceled.
|
JiwaniZakir
left a comment
JiwaniZakir
left a comment
There was a problem hiding this comment.
The data: ? change is the right fix per the WHATWG SSE spec, which allows an optional single space after the colon. However, the existing [^}]+ in the control match patterns (e.g., lines 1619 and 1717 in packages/server-conformance-tests/src/index.ts) remains fragile — it will silently fail to capture the full JSON payload if the control event data ever contains nested objects, since [^}] stops at the first closing brace. That's a pre-existing issue, but it's worth noting alongside this change since you're already touching these regex lines.
For the multiline data assertions around line 3419, switching from .toContain('data:line1') to .toMatch(/data: ?line1/) is correct, but consider whether a test case with exactly two spaces (data: line1) should be explicitly verified as non-conforming — the ? regex correctly rejects it, but there's no negative assertion to document that intent and catch a future regression if someone widens it to \s*.
|
hi @balegas (hope I'm asking the suitable person), could you please have a review? |
2 participants
Several SSE-related conformance tests use regexes like
data:({[^}]+})and assertions liketoContain("data:line1")that require no space after thedata:field name. This causes false failures against servers that outputdata: value(with space after the colon).The SSE specification explicitly states:
Both
data:helloanddata: helloare valid and produce the identical valuehello. Many HTTP frameworks (Axum, Actix, hyper, etc.) include the space by convention for readability.