Show More
@@ -368,3 +368,50 b' indicating which bundle types the server' | |||
|
368 | 368 | comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values |
|
369 | 369 | reflects the priority/preference of that type, where the first value is the |
|
370 | 370 | most preferred type. |
|
371 | ||
|
372 | Handshake Protocol | |
|
373 | ================== | |
|
374 | ||
|
375 | While not explicitly required, it is common for clients to perform a | |
|
376 | *handshake* when connecting to a server. The handshake accomplishes 2 things: | |
|
377 | ||
|
378 | * Obtaining capabilities and other server features | |
|
379 | * Flushing extra server output (e.g. SSH servers may print extra text | |
|
380 | when connecting that may confuse the wire protocol) | |
|
381 | ||
|
382 | This isn't a traditional *handshake* as far as network protocols go because | |
|
383 | there is no persistent state as a result of the handshake: the handshake is | |
|
384 | simply the issuing of commands and commands are stateless. | |
|
385 | ||
|
386 | The canonical clients perform a capabilities lookup at connection establishment | |
|
387 | time. This is because clients must assume a server only supports the features | |
|
388 | of the original Mercurial server implementation until proven otherwise (from | |
|
389 | advertised capabilities). Nearly every server running today supports features | |
|
390 | that weren't present in the original Mercurial server implementation. Rather | |
|
391 | than wait for a client to perform functionality that needs to consult | |
|
392 | capabilities, it issues the lookup at connection start to avoid any delay later. | |
|
393 | ||
|
394 | For HTTP servers, the client sends a ``capabilities`` command request as | |
|
395 | soon as the connection is established. The server responds with a capabilities | |
|
396 | string, which the client parses. | |
|
397 | ||
|
398 | For SSH servers, the client sends the ``hello`` command (no arguments) | |
|
399 | and a ``between`` command with the ``pairs`` argument having the value | |
|
400 | ``0000000000000000000000000000000000000000-0000000000000000000000000000000000000000``. | |
|
401 | ||
|
402 | The ``between`` command has been supported since the original Mercurial | |
|
403 | server. Requesting the empty range will return a ``\n`` string response, | |
|
404 | which will be encoded as ``1\n\n`` (value length of ``1`` followed by a newline | |
|
405 | followed by the value, which happens to be a newline). | |
|
406 | ||
|
407 | The ``hello`` command was later introduced. Servers supporting it will issue | |
|
408 | a response to that command before sending the ``1\n\n`` response to the | |
|
409 | ``between`` command. Servers not supporting ``hello`` will send an empty | |
|
410 | response (``0\n``). | |
|
411 | ||
|
412 | In addition to the expected output from the ``hello`` and ``between`` commands, | |
|
413 | servers may also send other output, such as *message of the day (MOTD)* | |
|
414 | announcements. Clients assume servers will send this output before the | |
|
415 | Mercurial server replies to the client-issued commands. So any server output | |
|
416 | not conforming to the expected command responses is assumed to be not related | |
|
417 | to Mercurial and can be ignored. |
General Comments 0
You need to be logged in to leave comments.
Login now