zit 0.3.6 fixes a clone failure against Fossil servers whose front web
server appends a parameter to the reply's Content-Type. zit clone of
libspatialite from gaia-gis.it stopped with "the peer's reply exceeded the
size limit"; it now completes.
No artifact, tag namespace, or sync message changed.
The failure
The server answers the first clone round with
Content-Type: application/x-fossil-uncompressed; charset=utf-8. zit
compared the header exactly against the three protocol media types, so the
; charset=utf-8 suffix matched none of them and the reply was treated as
the default, a zlib container. The plaintext body's first four bytes —
cfil, from the first cfile card — were then read as the container's
length: 1.6 GB, over the reply cap, hence the size message. The reply was
5 MB.
sync.parseMediaType now reads the media type up to the first ;, with
surrounding whitespace trimmed, and compares it case-insensitively — the
same tolerance fossil's own client has through its prefix compare. zit
serve already stripped the parameter on incoming requests through its own
copy of the logic; it uses the shared one now.
Compatibility
- Artifacts, tags, and the sync protocol are unchanged; Fossil RFC revision 00 remains the target.
- No on-disk format changed (the image schema stays at version 6).
- No command, flag, or output changed.
Qualification
zig build test, e2e, smoke (Fossil interop against a real fossil),
muscle (41 differential steps), git-import-e2e, git-export-e2e, and
dst, plus the three-runner CI battery (macOS ARM64, Linux x86-64, Linux
ARM64). Verified against the repository that failed: 0.3.5 stops on the
first round, 0.3.6 clones all 24,018 artifacts of libspatialite and its
timeline matches the server's.