|
| 1 | + Git Wire Protocol, Version 2 |
| 2 | +============================== |
| 3 | + |
| 4 | +This document presents a specification for a version 2 of Git's wire |
| 5 | +protocol. Protocol v2 will improve upon v1 in the following ways: |
| 6 | + |
| 7 | + * Instead of multiple service names, multiple commands will be |
| 8 | + supported by a single service |
| 9 | + * Easily extendable as capabilities are moved into their own section |
| 10 | + of the protocol, no longer being hidden behind a NUL byte and |
| 11 | + limited by the size of a pkt-line |
| 12 | + * Separate out other information hidden behind NUL bytes (e.g. agent |
| 13 | + string as a capability and symrefs can be requested using 'ls-refs') |
| 14 | + * Reference advertisement will be omitted unless explicitly requested |
| 15 | + * ls-refs command to explicitly request some refs |
| 16 | + * Designed with http and stateless-rpc in mind. With clear flush |
| 17 | + semantics the http remote helper can simply act as a proxy |
| 18 | + |
| 19 | +In protocol v2 communication is command oriented. When first contacting a |
| 20 | +server a list of capabilities will advertised. Some of these capabilities |
| 21 | +will be commands which a client can request be executed. Once a command |
| 22 | +has completed, a client can reuse the connection and request that other |
| 23 | +commands be executed. |
| 24 | + |
| 25 | + Packet-Line Framing |
| 26 | +--------------------- |
| 27 | + |
| 28 | +All communication is done using packet-line framing, just as in v1. See |
| 29 | +`Documentation/technical/pack-protocol.txt` and |
| 30 | +`Documentation/technical/protocol-common.txt` for more information. |
| 31 | + |
| 32 | +In protocol v2 these special packets will have the following semantics: |
| 33 | + |
| 34 | + * '0000' Flush Packet (flush-pkt) - indicates the end of a message |
| 35 | + * '0001' Delimiter Packet (delim-pkt) - separates sections of a message |
| 36 | + |
| 37 | + Initial Client Request |
| 38 | +------------------------ |
| 39 | + |
| 40 | +In general a client can request to speak protocol v2 by sending |
| 41 | +`version=2` through the respective side-channel for the transport being |
| 42 | +used which inevitably sets `GIT_PROTOCOL`. More information can be |
| 43 | +found in `pack-protocol.txt` and `http-protocol.txt`. In all cases the |
| 44 | +response from the server is the capability advertisement. |
| 45 | + |
| 46 | + Git Transport |
| 47 | +~~~~~~~~~~~~~~~ |
| 48 | + |
| 49 | +When using the git:// transport, you can request to use protocol v2 by |
| 50 | +sending "version=2" as an extra parameter: |
| 51 | + |
| 52 | + 003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0 |
| 53 | + |
| 54 | + SSH and File Transport |
| 55 | +~~~~~~~~~~~~~~~~~~~~~~~~ |
| 56 | + |
| 57 | +When using either the ssh:// or file:// transport, the GIT_PROTOCOL |
| 58 | +environment variable must be set explicitly to include "version=2". |
| 59 | + |
| 60 | + HTTP Transport |
| 61 | +~~~~~~~~~~~~~~~~ |
| 62 | + |
| 63 | +When using the http:// or https:// transport a client makes a "smart" |
| 64 | +info/refs request as described in `http-protocol.txt` and requests that |
| 65 | +v2 be used by supplying "version=2" in the `Git-Protocol` header. |
| 66 | + |
| 67 | + C: Git-Protocol: version=2 |
| 68 | + C: |
| 69 | + C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 |
| 70 | + |
| 71 | +A v2 server would reply: |
| 72 | + |
| 73 | + S: 200 OK |
| 74 | + S: <Some headers> |
| 75 | + S: ... |
| 76 | + S: |
| 77 | + S: 000eversion 2\n |
| 78 | + S: <capability-advertisement> |
| 79 | + |
| 80 | +Subsequent requests are then made directly to the service |
| 81 | +`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack). |
| 82 | + |
| 83 | + Capability Advertisement |
| 84 | +-------------------------- |
| 85 | + |
| 86 | +A server which decides to communicate (based on a request from a client) |
| 87 | +using protocol version 2, notifies the client by sending a version string |
| 88 | +in its initial response followed by an advertisement of its capabilities. |
| 89 | +Each capability is a key with an optional value. Clients must ignore all |
| 90 | +unknown keys. Semantics of unknown values are left to the definition of |
| 91 | +each key. Some capabilities will describe commands which can be requested |
| 92 | +to be executed by the client. |
| 93 | + |
| 94 | + capability-advertisement = protocol-version |
| 95 | + capability-list |
| 96 | + flush-pkt |
| 97 | + |
| 98 | + protocol-version = PKT-LINE("version 2" LF) |
| 99 | + capability-list = *capability |
| 100 | + capability = PKT-LINE(key[=value] LF) |
| 101 | + |
| 102 | + key = 1*(ALPHA | DIGIT | "-_") |
| 103 | + value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;") |
| 104 | + |
| 105 | + Command Request |
| 106 | +----------------- |
| 107 | + |
| 108 | +After receiving the capability advertisement, a client can then issue a |
| 109 | +request to select the command it wants with any particular capabilities |
| 110 | +or arguments. There is then an optional section where the client can |
| 111 | +provide any command specific parameters or queries. Only a single |
| 112 | +command can be requested at a time. |
| 113 | + |
| 114 | + request = empty-request | command-request |
| 115 | + empty-request = flush-pkt |
| 116 | + command-request = command |
| 117 | + capability-list |
| 118 | + [command-args] |
| 119 | + flush-pkt |
| 120 | + command = PKT-LINE("command=" key LF) |
| 121 | + command-args = delim-pkt |
| 122 | + *command-specific-arg |
| 123 | + |
| 124 | + command-specific-args are packet line framed arguments defined by |
| 125 | + each individual command. |
| 126 | + |
| 127 | +The server will then check to ensure that the client's request is |
| 128 | +comprised of a valid command as well as valid capabilities which were |
| 129 | +advertised. If the request is valid the server will then execute the |
| 130 | +command. A server MUST wait till it has received the client's entire |
| 131 | +request before issuing a response. The format of the response is |
| 132 | +determined by the command being executed, but in all cases a flush-pkt |
| 133 | +indicates the end of the response. |
| 134 | + |
| 135 | +When a command has finished, and the client has received the entire |
| 136 | +response from the server, a client can either request that another |
| 137 | +command be executed or can terminate the connection. A client may |
| 138 | +optionally send an empty request consisting of just a flush-pkt to |
| 139 | +indicate that no more requests will be made. |
| 140 | + |
| 141 | + Capabilities |
| 142 | +-------------- |
| 143 | + |
| 144 | +There are two different types of capabilities: normal capabilities, |
| 145 | +which can be used to to convey information or alter the behavior of a |
| 146 | +request, and commands, which are the core actions that a client wants to |
| 147 | +perform (fetch, push, etc). |
| 148 | + |
| 149 | +Protocol version 2 is stateless by default. This means that all commands |
| 150 | +must only last a single round and be stateless from the perspective of the |
| 151 | +server side, unless the client has requested a capability indicating that |
| 152 | +state should be maintained by the server. Clients MUST NOT require state |
| 153 | +management on the server side in order to function correctly. This |
| 154 | +permits simple round-robin load-balancing on the server side, without |
| 155 | +needing to worry about state management. |
| 156 | + |
| 157 | + agent |
| 158 | +~~~~~~~ |
| 159 | + |
| 160 | +The server can advertise the `agent` capability with a value `X` (in the |
| 161 | +form `agent=X`) to notify the client that the server is running version |
| 162 | +`X`. The client may optionally send its own agent string by including |
| 163 | +the `agent` capability with a value `Y` (in the form `agent=Y`) in its |
| 164 | +request to the server (but it MUST NOT do so if the server did not |
| 165 | +advertise the agent capability). The `X` and `Y` strings may contain any |
| 166 | +printable ASCII characters except space (i.e., the byte range 32 < x < |
| 167 | +127), and are typically of the form "package/version" (e.g., |
| 168 | +"git/1.8.3.1"). The agent strings are purely informative for statistics |
| 169 | +and debugging purposes, and MUST NOT be used to programmatically assume |
| 170 | +the presence or absence of particular features. |
0 commit comments