237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
|
Only one login card is permitted. A second login card will trigger
a sync error. (Prior to 2025-07-21, the protocol permitted multiple
logins, treating the login as the union of all privileges from all
login cards. That capability was never used and has been removed.)
As of version 2.27, Fossil supports transfering of the login card
externally to the request payload in one of the following ways:
<ul>
<li> URL parameter named "x-f-x-l".
<li> An HTTP header named "X-Fossil-Xfer-Login". The caveat for this
header is that CGI-hosted fossils cannot see the headers. It
works for standalone severs and connections running via fossil's
"test-http" mechanism.
</ul>
It is legal to use both of those approaches together but it is not
possible to use either of them with an in-body login card because
including an in-body login card would change the login card's value
for the header or URL parameter.
|
|
|
|
<
<
<
<
|
<
|
<
|
|
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
|
Only one login card is permitted. A second login card will trigger
a sync error. (Prior to 2025-07-21, the protocol permitted multiple
logins, treating the login as the union of all privileges from all
login cards. That capability was never used and has been removed.)
As of version 2.27, Fossil supports transfering of the login card
externally to the request payload via a Cookie HTTP header:
<verbatim>
Cookie: x-f-x-l=...
</verbatim>
Where "..." is the URL-encoded login cookie. <code>x-f-x-l</code> is
short for X-Fossil-Xfer-Login.
<h3 id="file">3.3 File Cards</h3>
Artifacts are transferred using either "file" cards, or "cfile"
or "uvfile" cards.
The name "file" card comes from the fact that most artifacts correspond to
|