# zit 0.3.6
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 (zit#179).
No artifact, tag namespace, or sync message changed.
## The failure (zit#179)
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.