You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: http-push-sse-protocol.md
+12-6Lines changed: 12 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,9 +38,16 @@ The goal is to reuse all message types, fragmentation rules, and semantics from
38
38
- Recommended headers:
39
39
-`Content-Type: application/octet-stream`
40
40
-`Content-Length: <frame size>`
41
-
- Push responses MAY return a protocol frame (binary) when the exchange is naturally request/response:
42
-
-`JoinRequest` → `JoinResponseOk` / `JoinError`
43
-
-`DocUpdate` / fragments completing a batch → `Ack`
41
+
- Response body: either empty or a single protocol frame (binary). If present, servers SHOULD use:
42
+
-`Content-Type: application/octet-stream`
43
+
44
+
In this transport profile, two flows are defined as request/response pairs:
45
+
46
+
-**Join:** when the client pushes a `JoinRequest`, the server MUST respond in the same HTTP response body with exactly one protocol frame:
47
+
-`JoinResponseOk`, or
48
+
-`JoinError`.
49
+
-**Client-originated updates:** when the client pushes a `DocUpdate` (single frame), the server MUST respond with an `Ack` frame in the same HTTP response body.
50
+
- For fragmented updates, the server MUST emit exactly one `Ack` per batch ID; it is RECOMMENDED to return it as the HTTP response to the push that completes the batch (typically the final fragment), or earlier if it can reject immediately.
44
51
45
52
For other push messages (e.g., `Leave`), the response body can be empty.
46
53
@@ -83,7 +90,7 @@ Security note: if the session key is sensitive, prefer cookie/header transport o
0 commit comments