Defines how StreamLD’s cursor-based subscription model (see StreamLD Core) is carried over Server-Sent Events, for server-to-client delivery. Part of the StreamLD module.
A client subscribes to a stream by opening an SSE connection to that stream’s
subscription endpoint. The connection MUST be served over HTTP/2 or later, to
avoid the six-connections-per-origin limit HTTP/1.1 imposes on `EventSource`.
2. Resumption
The StreamLD cursor (see StreamLD Core, The Cursor) is carried directly as the
SSE `id` field of each event. A reconnecting client’s browser automatically
resends the last-seen `id` as the `Last-Event-ID` request header; a
conformant server MUST treat an incoming `Last-Event-ID` header as the
`streamld:after` value of an implicit subscription request.
3. Gap responses
If the requested cursor cannot be satisfied (see StreamLD Core, Gap handling),
the server MUST respond with HTTP status 409
and a JSON body matching the `streamld:GapSignal` shape, and MUST NOT begin an
`text/event-stream` response in that case.
Conformance
Document conventions
Conformance requirements are expressed
with a combination of descriptive assertions
and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text
with class="example",
like this:
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text
with class="note",
like this: