]>
Commit | Line | Data |
---|---|---|
1e232016 ÆAB |
1 | gitprotocol-http(5) |
2 | =================== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | gitprotocol-http - Git HTTP-based protocols | |
7 | ||
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
11 | [verse] | |
12 | <over-the-wire-protocol> | |
13 | ||
14 | ||
15 | DESCRIPTION | |
16 | ----------- | |
4c6fffe2 SP |
17 | |
18 | Git supports two HTTP based transfer protocols. A "dumb" protocol | |
19 | which requires only a standard HTTP server on the server end of the | |
20 | connection, and a "smart" protocol which requires a Git aware CGI | |
21 | (or server module). This document describes both protocols. | |
22 | ||
23 | As a design feature smart clients can automatically upgrade "dumb" | |
24 | protocol URLs to smart URLs. This permits all users to have the | |
25 | same published URL, and the peers automatically select the most | |
26 | efficient transport available to them. | |
27 | ||
28 | ||
29 | URL Format | |
30 | ---------- | |
31 | ||
32 | URLs for Git repositories accessed by HTTP use the standard HTTP | |
33 | URL syntax documented by RFC 1738, so they are of the form: | |
34 | ||
35 | http://<host>:<port>/<path>?<searchpart> | |
36 | ||
586aa786 | 37 | Within this documentation the placeholder `$GIT_URL` will stand for |
4c6fffe2 SP |
38 | the http:// repository URL entered by the end-user. |
39 | ||
586aa786 | 40 | Servers SHOULD handle all requests to locations matching `$GIT_URL`, as |
4c6fffe2 SP |
41 | both the "smart" and "dumb" HTTP protocols used by Git operate |
42 | by appending additional path components onto the end of the user | |
586aa786 | 43 | supplied `$GIT_URL` string. |
4c6fffe2 | 44 | |
859a6d60 | 45 | An example of a dumb client requesting a loose object: |
4c6fffe2 SP |
46 | |
47 | $GIT_URL: http://example.com:8080/git/repo.git | |
48 | URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355 | |
49 | ||
50 | An example of a smart request to a catch-all gateway: | |
51 | ||
52 | $GIT_URL: http://example.com/daemon.cgi?svc=git&q= | |
53 | URL request: http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack | |
54 | ||
55 | An example of a request to a submodule: | |
56 | ||
57 | $GIT_URL: http://example.com/git/repo.git/path/submodule.git | |
58 | URL request: http://example.com/git/repo.git/path/submodule.git/info/refs | |
59 | ||
586aa786 TA |
60 | Clients MUST strip a trailing `/`, if present, from the user supplied |
61 | `$GIT_URL` string to prevent empty path tokens (`//`) from appearing | |
4c6fffe2 | 62 | in any URL sent to a server. Compatible clients MUST expand |
586aa786 | 63 | `$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`. |
4c6fffe2 SP |
64 | |
65 | ||
66 | Authentication | |
67 | -------------- | |
68 | ||
69 | Standard HTTP authentication is used if authentication is required | |
70 | to access a repository, and MAY be configured and enforced by the | |
71 | HTTP server software. | |
72 | ||
73 | Because Git repositories are accessed by standard path components | |
74 | server administrators MAY use directory based permissions within | |
75 | their HTTP server to control repository access. | |
76 | ||
04953bc8 | 77 | Clients SHOULD support Basic authentication as described by RFC 2617. |
4c6fffe2 SP |
78 | Servers SHOULD support Basic authentication by relying upon the |
79 | HTTP server placed in front of the Git server software. | |
80 | ||
81 | Servers SHOULD NOT require HTTP cookies for the purposes of | |
82 | authentication or access control. | |
83 | ||
84 | Clients and servers MAY support other common forms of HTTP based | |
85 | authentication, such as Digest authentication. | |
86 | ||
87 | ||
88 | SSL | |
89 | --- | |
90 | ||
91 | Clients and servers SHOULD support SSL, particularly to protect | |
92 | passwords when relying on Basic HTTP authentication. | |
93 | ||
94 | ||
95 | Session State | |
96 | ------------- | |
97 | ||
98 | The Git over HTTP protocol (much like HTTP itself) is stateless | |
99 | from the perspective of the HTTP server side. All state MUST be | |
100 | retained and managed by the client process. This permits simple | |
101 | round-robin load-balancing on the server side, without needing to | |
102 | worry about state management. | |
103 | ||
104 | Clients MUST NOT require state management on the server side in | |
105 | order to function correctly. | |
106 | ||
107 | Servers MUST NOT require HTTP cookies in order to function correctly. | |
108 | Clients MAY store and forward HTTP cookies during request processing | |
109 | as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any | |
110 | cookies sent by a client. | |
111 | ||
112 | ||
113 | General Request Processing | |
114 | -------------------------- | |
115 | ||
116 | Except where noted, all standard HTTP behavior SHOULD be assumed | |
117 | by both client and server. This includes (but is not necessarily | |
118 | limited to): | |
119 | ||
586aa786 TA |
120 | If there is no repository at `$GIT_URL`, or the resource pointed to by a |
121 | location matching `$GIT_URL` does not exist, the server MUST NOT respond | |
122 | with `200 OK` response. A server SHOULD respond with | |
123 | `404 Not Found`, `410 Gone`, or any other suitable HTTP status code | |
4c6fffe2 SP |
124 | which does not imply the resource exists as requested. |
125 | ||
586aa786 TA |
126 | If there is a repository at `$GIT_URL`, but access is not currently |
127 | permitted, the server MUST respond with the `403 Forbidden` HTTP | |
4c6fffe2 SP |
128 | status code. |
129 | ||
130 | Servers SHOULD support both HTTP 1.0 and HTTP 1.1. | |
131 | Servers SHOULD support chunked encoding for both request and response | |
132 | bodies. | |
133 | ||
134 | Clients SHOULD support both HTTP 1.0 and HTTP 1.1. | |
135 | Clients SHOULD support chunked encoding for both request and response | |
136 | bodies. | |
137 | ||
138 | Servers MAY return ETag and/or Last-Modified headers. | |
139 | ||
140 | Clients MAY revalidate cached entities by including If-Modified-Since | |
141 | and/or If-None-Match request headers. | |
142 | ||
586aa786 | 143 | Servers MAY return `304 Not Modified` if the relevant headers appear |
4c6fffe2 | 144 | in the request and the entity has not changed. Clients MUST treat |
586aa786 | 145 | `304 Not Modified` identical to `200 OK` by reusing the cached entity. |
4c6fffe2 SP |
146 | |
147 | Clients MAY reuse a cached entity without revalidation if the | |
148 | Cache-Control and/or Expires header permits caching. Clients and | |
149 | servers MUST follow RFC 2616 for cache controls. | |
150 | ||
151 | ||
152 | Discovering References | |
153 | ---------------------- | |
154 | ||
155 | All HTTP clients MUST begin either a fetch or a push exchange by | |
156 | discovering the references available on the remote repository. | |
157 | ||
158 | Dumb Clients | |
159 | ~~~~~~~~~~~~ | |
160 | ||
161 | HTTP clients that only support the "dumb" protocol MUST discover | |
162 | references by making a request for the special info/refs file of | |
163 | the repository. | |
164 | ||
586aa786 | 165 | Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`, |
4c6fffe2 SP |
166 | without any search/query parameters. |
167 | ||
168 | C: GET $GIT_URL/info/refs HTTP/1.0 | |
169 | ||
170 | S: 200 OK | |
171 | S: | |
172 | S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint | |
173 | S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master | |
174 | S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 | |
175 | S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} | |
176 | ||
177 | The Content-Type of the returned info/refs entity SHOULD be | |
586aa786 | 178 | `text/plain; charset=utf-8`, but MAY be any content type. |
4c6fffe2 SP |
179 | Clients MUST NOT attempt to validate the returned Content-Type. |
180 | Dumb servers MUST NOT return a return type starting with | |
586aa786 | 181 | `application/x-git-`. |
4c6fffe2 SP |
182 | |
183 | Cache-Control headers MAY be returned to disable caching of the | |
184 | returned entity. | |
185 | ||
186 | When examining the response clients SHOULD only examine the HTTP | |
586aa786 | 187 | status code. Valid responses are `200 OK`, or `304 Not Modified`. |
4c6fffe2 SP |
188 | |
189 | The returned content is a UNIX formatted text file describing | |
190 | each ref and its known value. The file SHOULD be sorted by name | |
191 | according to the C locale ordering. The file SHOULD NOT include | |
586aa786 | 192 | the default ref named `HEAD`. |
4c6fffe2 SP |
193 | |
194 | info_refs = *( ref_record ) | |
195 | ref_record = any_ref / peeled_ref | |
196 | ||
197 | any_ref = obj-id HTAB refname LF | |
198 | peeled_ref = obj-id HTAB refname LF | |
199 | obj-id HTAB refname "^{}" LF | |
200 | ||
201 | Smart Clients | |
202 | ~~~~~~~~~~~~~ | |
203 | ||
204 | HTTP clients that support the "smart" protocol (or both the | |
205 | "smart" and "dumb" protocols) MUST discover references by making | |
206 | a parameterized request for the info/refs file of the repository. | |
207 | ||
208 | The request MUST contain exactly one query parameter, | |
586aa786 | 209 | `service=$servicename`, where `$servicename` MUST be the service |
4c6fffe2 SP |
210 | name the client wishes to contact to complete the operation. |
211 | The request MUST NOT contain additional query parameters. | |
212 | ||
213 | C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 | |
214 | ||
586aa786 TA |
215 | dumb server reply: |
216 | ||
4c6fffe2 SP |
217 | S: 200 OK |
218 | S: | |
219 | S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint | |
220 | S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master | |
221 | S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 | |
222 | S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} | |
223 | ||
586aa786 TA |
224 | smart server reply: |
225 | ||
4c6fffe2 SP |
226 | S: 200 OK |
227 | S: Content-Type: application/x-git-upload-pack-advertisement | |
228 | S: Cache-Control: no-cache | |
229 | S: | |
230 | S: 001e# service=git-upload-pack\n | |
0aa7a780 | 231 | S: 0000 |
4c6fffe2 | 232 | S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n |
2c31a7aa | 233 | S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n |
4c6fffe2 SP |
234 | S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n |
235 | S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n | |
0aa7a780 | 236 | S: 0000 |
4c6fffe2 | 237 | |
6464679d | 238 | The client may send Extra Parameters (see |
5db92105 | 239 | linkgit:gitprotocol-pack[5]) as a colon-separated string |
6464679d JT |
240 | in the Git-Protocol HTTP header. |
241 | ||
98e2d9d6 ÆAB |
242 | Uses the `--http-backend-info-refs` option to |
243 | linkgit:git-upload-pack[1]. | |
244 | ||
4c6fffe2 SP |
245 | Dumb Server Response |
246 | ^^^^^^^^^^^^^^^^^^^^ | |
247 | Dumb servers MUST respond with the dumb server reply format. | |
248 | ||
249 | See the prior section under dumb clients for a more detailed | |
250 | description of the dumb server response. | |
251 | ||
252 | Smart Server Response | |
253 | ^^^^^^^^^^^^^^^^^^^^^ | |
254 | If the server does not recognize the requested service name, or the | |
255 | requested service name has been disabled by the server administrator, | |
586aa786 | 256 | the server MUST respond with the `403 Forbidden` HTTP status code. |
4c6fffe2 SP |
257 | |
258 | Otherwise, smart servers MUST respond with the smart server reply | |
259 | format for the requested service name. | |
260 | ||
261 | Cache-Control headers SHOULD be used to disable caching of the | |
262 | returned entity. | |
263 | ||
586aa786 | 264 | The Content-Type MUST be `application/x-$servicename-advertisement`. |
4c6fffe2 SP |
265 | Clients SHOULD fall back to the dumb protocol if another content |
266 | type is returned. When falling back to the dumb protocol clients | |
586aa786 | 267 | SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but |
4c6fffe2 SP |
268 | instead SHOULD use the response already in hand. Clients MUST NOT |
269 | continue if they do not support the dumb protocol. | |
270 | ||
586aa786 TA |
271 | Clients MUST validate the status code is either `200 OK` or |
272 | `304 Not Modified`. | |
4c6fffe2 SP |
273 | |
274 | Clients MUST validate the first five bytes of the response entity | |
586aa786 | 275 | matches the regex `^[0-9a-f]{4}#`. If this test fails, clients |
4c6fffe2 SP |
276 | MUST NOT continue. |
277 | ||
278 | Clients MUST parse the entire response as a sequence of pkt-line | |
279 | records. | |
280 | ||
586aa786 | 281 | Clients MUST verify the first pkt-line is `# service=$servicename`. |
4c6fffe2 SP |
282 | Servers MUST set $servicename to be the request parameter value. |
283 | Servers SHOULD include an LF at the end of this line. | |
284 | Clients MUST ignore an LF at the end of the line. | |
285 | ||
586aa786 | 286 | Servers MUST terminate the response with the magic `0000` end |
4c6fffe2 SP |
287 | pkt-line marker. |
288 | ||
289 | The returned response is a pkt-line stream describing each ref and | |
290 | its known value. The stream SHOULD be sorted by name according to | |
291 | the C locale ordering. The stream SHOULD include the default ref | |
586aa786 | 292 | named `HEAD` as the first ref. The stream MUST include capability |
4c6fffe2 SP |
293 | declarations behind a NUL on the first ref. |
294 | ||
6464679d JT |
295 | The returned response contains "version 1" if "version=1" was sent as an |
296 | Extra Parameter. | |
297 | ||
4c6fffe2 | 298 | smart_reply = PKT-LINE("# service=$servicename" LF) |
0aa7a780 | 299 | "0000" |
6464679d | 300 | *1("version 1") |
4c6fffe2 SP |
301 | ref_list |
302 | "0000" | |
303 | ref_list = empty_list / non_empty_list | |
304 | ||
305 | empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF) | |
306 | ||
307 | non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF) | |
308 | *ref_record | |
309 | ||
310 | cap-list = capability *(SP capability) | |
311 | capability = 1*(LC_ALPHA / DIGIT / "-" / "_") | |
312 | LC_ALPHA = %x61-7A | |
313 | ||
314 | ref_record = any_ref / peeled_ref | |
315 | any_ref = PKT-LINE(obj-id SP name LF) | |
316 | peeled_ref = PKT-LINE(obj-id SP name LF) | |
317 | PKT-LINE(obj-id SP name "^{}" LF | |
318 | ||
586aa786 | 319 | |
4c6fffe2 SP |
320 | Smart Service git-upload-pack |
321 | ------------------------------ | |
586aa786 | 322 | This service reads from the repository pointed to by `$GIT_URL`. |
4c6fffe2 SP |
323 | |
324 | Clients MUST first perform ref discovery with | |
586aa786 | 325 | `$GIT_URL/info/refs?service=git-upload-pack`. |
4c6fffe2 SP |
326 | |
327 | C: POST $GIT_URL/git-upload-pack HTTP/1.0 | |
328 | C: Content-Type: application/x-git-upload-pack-request | |
329 | C: | |
330 | C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n | |
331 | C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n | |
332 | C: 0000 | |
333 | ||
334 | S: 200 OK | |
335 | S: Content-Type: application/x-git-upload-pack-result | |
336 | S: Cache-Control: no-cache | |
337 | S: | |
338 | S: ....ACK %s, continue | |
339 | S: ....NAK | |
340 | ||
7e7cf80d | 341 | Clients MUST NOT reuse or revalidate a cached response. |
4c6fffe2 SP |
342 | Servers MUST include sufficient Cache-Control headers |
343 | to prevent caching of the response. | |
344 | ||
345 | Servers SHOULD support all capabilities defined here. | |
346 | ||
586aa786 TA |
347 | Clients MUST send at least one "want" command in the request body. |
348 | Clients MUST NOT reference an id in a "want" command which did not | |
4c6fffe2 | 349 | appear in the response obtained through ref discovery unless the |
68ee6289 FM |
350 | server advertises capability `allow-tip-sha1-in-want` or |
351 | `allow-reachable-sha1-in-want`. | |
4c6fffe2 SP |
352 | |
353 | compute_request = want_list | |
354 | have_list | |
355 | request_end | |
356 | request_end = "0000" / "done" | |
357 | ||
74258766 | 358 | want_list = PKT-LINE(want SP cap_list LF) |
4c6fffe2 SP |
359 | *(want_pkt) |
360 | want_pkt = PKT-LINE(want LF) | |
361 | want = "want" SP id | |
74258766 | 362 | cap_list = capability *(SP capability) |
4c6fffe2 SP |
363 | |
364 | have_list = *PKT-LINE("have" SP id LF) | |
365 | ||
366 | TODO: Document this further. | |
4c6fffe2 SP |
367 | |
368 | The Negotiation Algorithm | |
369 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
370 | The computation to select the minimal pack proceeds as follows | |
586aa786 TA |
371 | (C = client, S = server): |
372 | ||
373 | 'init step:' | |
374 | ||
375 | C: Use ref discovery to obtain the advertised refs. | |
376 | ||
9c96c7f3 | 377 | C: Place any object seen into set `advertised`. |
4c6fffe2 | 378 | |
9c96c7f3 | 379 | C: Build an empty set, `common`, to hold the objects that are later |
586aa786 | 380 | determined to be on both ends. |
4c6fffe2 | 381 | |
cf6cac20 | 382 | C: Build a set, `want`, of the objects from `advertised` that the client |
586aa786 | 383 | wants to fetch, based on what it saw during ref discovery. |
4c6fffe2 | 384 | |
9c96c7f3 | 385 | C: Start a queue, `c_pending`, ordered by commit time (popping newest |
586aa786 TA |
386 | first). Add all client refs. When a commit is popped from |
387 | the queue its parents SHOULD be automatically inserted back. | |
388 | Commits MUST only enter the queue once. | |
4c6fffe2 | 389 | |
586aa786 TA |
390 | 'one compute step:' |
391 | ||
392 | C: Send one `$GIT_URL/git-upload-pack` request: | |
4c6fffe2 | 393 | |
9c96c7f3 TA |
394 | C: 0032want <want #1>............................... |
395 | C: 0032want <want #2>............................... | |
4c6fffe2 | 396 | .... |
9c96c7f3 TA |
397 | C: 0032have <common #1>............................. |
398 | C: 0032have <common #2>............................. | |
4c6fffe2 | 399 | .... |
9c96c7f3 TA |
400 | C: 0032have <have #1>............................... |
401 | C: 0032have <have #2>............................... | |
4c6fffe2 SP |
402 | .... |
403 | C: 0000 | |
404 | ||
586aa786 | 405 | The stream is organized into "commands", with each command |
06ab60c0 | 406 | appearing by itself in a pkt-line. Within a command line, |
586aa786 TA |
407 | the text leading up to the first space is the command name, |
408 | and the remainder of the line to the first LF is the value. | |
409 | Command lines are terminated with an LF as the last byte of | |
410 | the pkt-line value. | |
4c6fffe2 | 411 | |
586aa786 TA |
412 | Commands MUST appear in the following order, if they appear |
413 | at all in the request stream: | |
4c6fffe2 | 414 | |
586aa786 TA |
415 | * "want" |
416 | * "have" | |
4c6fffe2 | 417 | |
586aa786 | 418 | The stream is terminated by a pkt-line flush (`0000`). |
4c6fffe2 | 419 | |
586aa786 | 420 | A single "want" or "have" command MUST have one hex formatted |
5b6422a6 MÅ |
421 | object name as its value. Multiple object names MUST be sent by sending |
422 | multiple commands. Object names MUST be given using the object format | |
423 | negotiated through the `object-format` capability (default SHA-1). | |
4c6fffe2 | 424 | |
9c96c7f3 | 425 | The `have` list is created by popping the first 32 commits |
cf6cac20 | 426 | from `c_pending`. Fewer can be supplied if `c_pending` empties. |
4c6fffe2 | 427 | |
9c96c7f3 TA |
428 | If the client has sent 256 "have" commits and has not yet |
429 | received one of those back from `s_common`, or the client has | |
430 | emptied `c_pending` it SHOULD include a "done" command to let | |
586aa786 | 431 | the server know it won't proceed: |
4c6fffe2 SP |
432 | |
433 | C: 0009done | |
434 | ||
586aa786 | 435 | S: Parse the git-upload-pack request: |
4c6fffe2 | 436 | |
9c96c7f3 | 437 | Verify all objects in `want` are directly reachable from refs. |
4c6fffe2 | 438 | |
586aa786 TA |
439 | The server MAY walk backwards through history or through |
440 | the reflog to permit slightly stale requests. | |
4c6fffe2 | 441 | |
9c96c7f3 | 442 | If no "want" objects are received, send an error: |
586aa786 | 443 | TODO: Define error if no "want" lines are requested. |
4c6fffe2 | 444 | |
9c96c7f3 | 445 | If any "want" object is not reachable, send an error: |
586aa786 | 446 | TODO: Define error if an invalid "want" is requested. |
4c6fffe2 | 447 | |
9c96c7f3 | 448 | Create an empty list, `s_common`. |
4c6fffe2 | 449 | |
586aa786 | 450 | If "have" was sent: |
4c6fffe2 | 451 | |
586aa786 | 452 | Loop through the objects in the order supplied by the client. |
4c6fffe2 | 453 | |
586aa786 | 454 | For each object, if the server has the object reachable from |
9c96c7f3 TA |
455 | a ref, add it to `s_common`. If a commit is added to `s_common`, |
456 | do not add any ancestors, even if they also appear in `have`. | |
4c6fffe2 | 457 | |
586aa786 | 458 | S: Send the git-upload-pack response: |
4c6fffe2 | 459 | |
586aa786 TA |
460 | If the server has found a closed set of objects to pack or the |
461 | request ends with "done", it replies with the pack. | |
4c6fffe2 | 462 | TODO: Document the pack based response |
4c6fffe2 | 463 | |
586aa786 | 464 | S: PACK... |
4c6fffe2 | 465 | |
586aa786 TA |
466 | The returned stream is the side-band-64k protocol supported |
467 | by the git-upload-pack service, and the pack is embedded into | |
468 | stream 1. Progress messages from the server side MAY appear | |
469 | in stream 2. | |
4c6fffe2 | 470 | |
586aa786 | 471 | Here a "closed set of objects" is defined to have at least |
9c96c7f3 | 472 | one path from every "want" to at least one "common" object. |
4c6fffe2 | 473 | |
586aa786 TA |
474 | If the server needs more information, it replies with a |
475 | status continue response: | |
4c6fffe2 SP |
476 | TODO: Document the non-pack response |
477 | ||
586aa786 TA |
478 | C: Parse the upload-pack response: |
479 | TODO: Document parsing response | |
4c6fffe2 | 480 | |
586aa786 | 481 | 'Do another compute step.' |
4c6fffe2 SP |
482 | |
483 | ||
484 | Smart Service git-receive-pack | |
485 | ------------------------------ | |
586aa786 | 486 | This service reads from the repository pointed to by `$GIT_URL`. |
4c6fffe2 SP |
487 | |
488 | Clients MUST first perform ref discovery with | |
586aa786 | 489 | `$GIT_URL/info/refs?service=git-receive-pack`. |
4c6fffe2 SP |
490 | |
491 | C: POST $GIT_URL/git-receive-pack HTTP/1.0 | |
492 | C: Content-Type: application/x-git-receive-pack-request | |
493 | C: | |
494 | C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status | |
495 | C: 0000 | |
496 | C: PACK.... | |
497 | ||
498 | S: 200 OK | |
499 | S: Content-Type: application/x-git-receive-pack-result | |
500 | S: Cache-Control: no-cache | |
501 | S: | |
502 | S: .... | |
503 | ||
7e7cf80d | 504 | Clients MUST NOT reuse or revalidate a cached response. |
4c6fffe2 SP |
505 | Servers MUST include sufficient Cache-Control headers |
506 | to prevent caching of the response. | |
507 | ||
508 | Servers SHOULD support all capabilities defined here. | |
509 | ||
510 | Clients MUST send at least one command in the request body. | |
511 | Within the command portion of the request body clients SHOULD send | |
512 | the id obtained through ref discovery as old_id. | |
513 | ||
514 | update_request = command_list | |
515 | "PACK" <binary data> | |
516 | ||
517 | command_list = PKT-LINE(command NUL cap_list LF) | |
518 | *(command_pkt) | |
519 | command_pkt = PKT-LINE(command LF) | |
520 | cap_list = *(SP capability) SP | |
521 | ||
522 | command = create / delete / update | |
523 | create = zero-id SP new_id SP name | |
524 | delete = old_id SP zero-id SP name | |
525 | update = old_id SP new_id SP name | |
526 | ||
527 | TODO: Document this further. | |
528 | ||
1e232016 | 529 | REFERENCES |
4c6fffe2 SP |
530 | ---------- |
531 | ||
d05b08cd JS |
532 | https://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] |
533 | https://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] | |
1e232016 ÆAB |
534 | |
535 | SEE ALSO | |
536 | -------- | |
537 | ||
5db92105 ÆAB |
538 | linkgit:gitprotocol-pack[5] |
539 | linkgit:gitprotocol-capabilities[5] | |
1e232016 ÆAB |
540 | |
541 | GIT | |
542 | --- | |
543 | Part of the linkgit:git[1] suite |