Merge branch 'js/trace2-session-id'
The transport layer was taught to optionally exchange the session ID assigned by the trace2 subsystem during fetch/push transactions. * js/trace2-session-id: receive-pack: log received client session ID send-pack: advertise session ID in capabilities upload-pack, serve: log received client session ID fetch-pack: advertise session ID in capabilities transport: log received server session ID serve: advertise session ID in v2 capabilities receive-pack: advertise session ID in v0 capabilities upload-pack: advertise session ID in v0 capabilities trace2: add a public function for getting the SID docs: new transfer.advertiseSID option docs: new capability to advertise session IDs
This commit is contained in:
@ -69,3 +69,7 @@ transfer.unpackLimit::
|
||||
When `fetch.unpackLimit` or `receive.unpackLimit` are
|
||||
not set, the value of this variable is used instead.
|
||||
The default value is 100.
|
||||
|
||||
transfer.advertiseSID::
|
||||
Boolean. When true, client and server processes will advertise their
|
||||
unique session IDs to their remote counterpart. Defaults to false.
|
||||
|
||||
@ -27,8 +27,8 @@ and 'push-cert' capabilities are sent and recognized by the receive-pack
|
||||
(push to server) process.
|
||||
|
||||
The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
|
||||
by both upload-pack and receive-pack protocols. The 'agent' capability
|
||||
may optionally be sent in both protocols.
|
||||
by both upload-pack and receive-pack protocols. The 'agent' and 'session-id'
|
||||
capabilities may optionally be sent in both protocols.
|
||||
|
||||
All other capabilities are only recognized by the upload-pack (fetch
|
||||
from server) process.
|
||||
@ -365,3 +365,16 @@ If the upload-pack server advertises the 'filter' capability,
|
||||
fetch-pack may send "filter" commands to request a partial clone
|
||||
or partial fetch and request that the server omit various objects
|
||||
from the packfile.
|
||||
|
||||
session-id=<session id>
|
||||
-----------------------
|
||||
|
||||
The server may advertise a session ID that can be used to identify this process
|
||||
across multiple requests. The client may advertise its own session ID back to
|
||||
the server as well.
|
||||
|
||||
Session IDs should be unique to a given process. They must fit within a
|
||||
packet-line, and must not contain non-printable or whitespace characters. The
|
||||
current implementation uses trace2 session IDs (see
|
||||
link:api-trace2.html[api-trace2] for details), but this may change and users of
|
||||
the session ID should not rely on this fact.
|
||||
|
||||
@ -492,3 +492,16 @@ form `object-format=X`) to notify the client that the server is able to deal
|
||||
with objects using hash algorithm X. If not specified, the server is assumed to
|
||||
only handle SHA-1. If the client would like to use a hash algorithm other than
|
||||
SHA-1, it should specify its object-format string.
|
||||
|
||||
session-id=<session id>
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The server may advertise a session ID that can be used to identify this process
|
||||
across multiple requests. The client may advertise its own session ID back to
|
||||
the server as well.
|
||||
|
||||
Session IDs should be unique to a given process. They must fit within a
|
||||
packet-line, and must not contain non-printable or whitespace characters. The
|
||||
current implementation uses trace2 session IDs (see
|
||||
link:api-trace2.html[api-trace2] for details), but this may change and users of
|
||||
the session ID should not rely on this fact.
|
||||
|
||||
Reference in New Issue
Block a user