| Document | draft-fossil-sync-protocol-01 |
| Section | 6.6 — Capability Model (file and cfile cards when push is not enabled) |
| Type | Technical (the text says later cards are still processed; Fossil stops at the first file or cfile card) |
| Status | Applied in draft-fossil-sync-protocol-01 (2026-10-12) |
| Reported | 2026-10-12 |
| Submitter | Dan Mestas |
| Found via | A reader implementing §6.6 from the text alone, then Fossil's source |
1. Summary
The -01 refusal paragraph says that after a refused push "later file and
cfile cards are refused individually, and later cards, including a pull, are
still processed". The form of the refusal is not given, and the second half
is wrong: in Fossil the first file or cfile card that arrives while push is
not enabled is answered with a reset error not authorized to write and
ends card processing for the request.
2. Location
§6.6, the sentence beginning "In both forms push is not enabled for the request".
3. The reference behavior
Fossil 2.28 page_xfer() (src/xfer.c:1360-1392): for a file or cfile
card, if( !isPush ) resets the accumulated output, emits
error not\sauthorized\sto\swrite, increments the error count, and executes
break, which leaves the card loop. The same break follows a handler
validation failure. A uvfile card is not gated on push and continues.
After the loop, the end-of-request work for an accepted pull still runs
(:1922-1925), as §6.4 already states for a failed login.
4. Impact
Observable. A conforming server that keeps parsing would answer a later
pull card with inventory that Fossil would not send, and would process
cards Fossil never reads.
5. Correction
- forms push is not enabled for the request, so later file and cfile
- cards are refused individually, and later cards, including a pull,
- are still processed. A client that sends both cards SHOULD send
+ forms push is not enabled for the request. Later cards, including
+ a pull, are still processed until the first file or cfile card:
+ that card is refused with reset output and error not authorized to
+ write, and ends card processing for the request, as a handler
+ validation failure does (Section 5.2). The end-of-request steps
+ for a direction established earlier, such as the igot inventory
+ for an accepted pull, are still performed (Section 6.4). A client
+ that sends both cards SHOULD send
6. Rationale
States the refusal form and the stop, which are the same reset-and-stop shape §5.2 already defines for handler failures.
7. Verification
- Source: Fossil 2.28
src/xfer.c:1360-1392,:1922-1925.