The server is listening for incoming HTTP requests.  The client
issues one or more HTTP requests and receives replies for each
request.

The server might be running as an independent server
using the [/help?cmd=server|"fossil server" command], or it
might be launched from inetd or xinetd using the
[/help?cmd=http|"fossil http" command].  Or the server might
be [./server/any/cgi.md|launched from CGI] or from
[./server/any/scgi.md|SCGI].
(See "[./server/|How To Configure A Fossil Server]" for details.)
The specifics of how the server listens
for incoming HTTP requests is immaterial to this protocol.
The important point is that the server is listening for requests and
the client is the issuer of the requests.

A single [/help?cmd=push|push],
[/help?cmd=pull|pull], or [/help?cmd=sync|sync]
might involve multiple HTTP requests.
The client maintains state between all requests.  But on the server
side, each request is independent.  The server does not preserve
any information about the client from one request to the next.

Note: Throughout this article, we use the terms "server" and "client"

The "cfile" name is an abbreviation for "compressed file".
The "uvfile" name is an abbreviation for "unversioned file".

<h4 id="ordinary-fc">3.3.1 Ordinary File Cards</h4>

For sync protocols, artifacts are transferred using "file"
cards.  File cards come in two different formats depending
on whether the artifact is sent directly or as a
[./delta_format.wiki|delta] from some
other artifact.

<pre>
<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i>
<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
</pre>

The first argument of a file card is the ID of the artifact that
is being transferred.  The artifact ID is the lower-case hexadecimal
representation of the name hash for the artifact.
The last argument of the file card is the number of bytes of
payload that immediately follow the file card.  If the file
card has only two arguments, that means the payload is the
complete content of the artifact.  If the file card has three
arguments, then the payload is a
[./delta_format.wiki|delta] and the second argument is
the ID of another artifact that is the source of the delta.

File cards are sent in both directions: client to server and
server to client.  A delta might be sent before the source of
the delta, so both client and server should remember deltas
and be able to apply them when their source arrives.

<h4 id="compressed-fc">3.3.2 Compressed File Cards</h4>

A client that sends a clone protocol version "3" or greater will
receive artifacts as "cfile" cards while cloning.  This card was
introduced to improve the speed of the transfer of content by sending
the compressed artifact directly from the server database to the
client.  In this case, the containing response body is <em>not</em>
compressed separately because the vast majority of the response is
already compressed in cfile cards. In practice, version "3" is
significantly faster than version "2".

Compressed File cards are similar to File cards, sharing the same
in-line "payload" data characteristics and also the same treatment of
direct content or delta content.  Cfile cards come in two different formats
depending on whether the artifact is sent directly or as a delta from
some other artifact.