| blob | 45ff15fa24c2724d79d4bbc01404bde36839b9fb |
1 '\" t
2 .\" Title: gitprotocol-http
3 .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
4 .\" Generator: DocBook XSL Stylesheets v1.79.2 <http://docbook.sf.net/>
5 .\" Date: 2024-11-20
6 .\" Manual: Git Manual
7 .\" Source: Git 2.47.0.305.g4083a6f052
8 .\" Language: English
9 .\"
10 .TH "GITPROTOCOL\-HTTP" "5" "2024-11-20" "Git 2\&.47\&.0\&.305\&.g4083a6" "Git Manual"
11 .\" -----------------------------------------------------------------
12 .\" * Define some portability stuff
13 .\" -----------------------------------------------------------------
14 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15 .\" http://bugs.debian.org/507673
16 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
17 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18 .ie \n(.g .ds Aq \(aq
19 .el .ds Aq '
20 .\" -----------------------------------------------------------------
21 .\" * set default formatting
22 .\" -----------------------------------------------------------------
23 .\" disable hyphenation
24 .nh
25 .\" disable justification (adjust text to left margin only)
26 .ad l
27 .\" -----------------------------------------------------------------
28 .\" * MAIN CONTENT STARTS HERE *
29 .\" -----------------------------------------------------------------
30 .SH "NAME"
31 gitprotocol-http \- Git HTTP\-based protocols
32 .SH "SYNOPSIS"
33 .sp
34 .nf
35 <over\-the\-wire\-protocol>
36 .fi
37 .SH "DESCRIPTION"
38 .sp
39 Git supports two HTTP based transfer protocols\&. A "dumb" protocol which requires only a standard HTTP server on the server end of the connection, and a "smart" protocol which requires a Git aware CGI (or server module)\&. This document describes both protocols\&.
40 .sp
41 As a design feature smart clients can automatically upgrade "dumb" protocol URLs to smart URLs\&. This permits all users to have the same published URL, and the peers automatically select the most efficient transport available to them\&.
42 .SH "URL FORMAT"
43 .sp
44 URLs for Git repositories accessed by HTTP use the standard HTTP URL syntax documented by RFC 1738, so they are of the form:
45 .sp
46 .if n \{\
47 .RS 4
48 .\}
49 .nf
50 http://<host>:<port>/<path>?<searchpart>
51 .fi
52 .if n \{\
53 .RE
54 .\}
55 .sp
56 Within this documentation the placeholder \fB$GIT_URL\fR will stand for the http:// repository URL entered by the end\-user\&.
57 .sp
58 Servers SHOULD handle all requests to locations matching \fB$GIT_URL\fR, as both the "smart" and "dumb" HTTP protocols used by Git operate by appending additional path components onto the end of the user supplied \fB$GIT_URL\fR string\&.
59 .sp
60 An example of a dumb client requesting a loose object:
61 .sp
62 .if n \{\
63 .RS 4
64 .\}
65 .nf
66 $GIT_URL: http://example\&.com:8080/git/repo\&.git
67 URL request: http://example\&.com:8080/git/repo\&.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
68 .fi
69 .if n \{\
70 .RE
71 .\}
72 .sp
73 An example of a smart request to a catch\-all gateway:
74 .sp
75 .if n \{\
76 .RS 4
77 .\}
78 .nf
79 $GIT_URL: http://example\&.com/daemon\&.cgi?svc=git&q=
80 URL request: http://example\&.com/daemon\&.cgi?svc=git&q=/info/refs&service=git\-receive\-pack
81 .fi
82 .if n \{\
83 .RE
84 .\}
85 .sp
86 An example of a request to a submodule:
87 .sp
88 .if n \{\
89 .RS 4
90 .\}
91 .nf
92 $GIT_URL: http://example\&.com/git/repo\&.git/path/submodule\&.git
93 URL request: http://example\&.com/git/repo\&.git/path/submodule\&.git/info/refs
94 .fi
95 .if n \{\
96 .RE
97 .\}
98 .sp
99 Clients MUST strip a trailing \fB/\fR, if present, from the user supplied \fB$GIT_URL\fR string to prevent empty path tokens (\fB//\fR) from appearing in any URL sent to a server\&. Compatible clients MUST expand \fB$GIT_URL/info/refs\fR as \fBfoo/info/refs\fR and not \fBfoo//info/refs\fR\&.
100 .SH "AUTHENTICATION"
101 .sp
102 Standard HTTP authentication is used if authentication is required to access a repository, and MAY be configured and enforced by the HTTP server software\&.
103 .sp
104 Because Git repositories are accessed by standard path components server administrators MAY use directory based permissions within their HTTP server to control repository access\&.
105 .sp
106 Clients SHOULD support Basic authentication as described by RFC 2617\&. Servers SHOULD support Basic authentication by relying upon the HTTP server placed in front of the Git server software\&.
107 .sp
108 Servers SHOULD NOT require HTTP cookies for the purposes of authentication or access control\&.
109 .sp
110 Clients and servers MAY support other common forms of HTTP based authentication, such as Digest authentication\&.
111 .SH "SSL"
112 .sp
113 Clients and servers SHOULD support SSL, particularly to protect passwords when relying on Basic HTTP authentication\&.
114 .SH "SESSION STATE"
115 .sp
116 The Git over HTTP protocol (much like HTTP itself) is stateless from the perspective of the HTTP server side\&. All state MUST be retained and managed by the client process\&. This permits simple round\-robin load\-balancing on the server side, without needing to worry about state management\&.
117 .sp
118 Clients MUST NOT require state management on the server side in order to function correctly\&.
119 .sp
120 Servers MUST NOT require HTTP cookies in order to function correctly\&. Clients MAY store and forward HTTP cookies during request processing as described by RFC 2616 (HTTP/1\&.1)\&. Servers SHOULD ignore any cookies sent by a client\&.
121 .SH "GENERAL REQUEST PROCESSING"
122 .sp
123 Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server\&. This includes (but is not necessarily limited to):
124 .sp
125 If there is no repository at \fB$GIT_URL\fR, or the resource pointed to by a location matching \fB$GIT_URL\fR does not exist, the server MUST NOT respond with \fB200\fR \fBOK\fR response\&. A server SHOULD respond with \fB404\fR \fBNot\fR \fBFound\fR, \fB410\fR \fBGone\fR, or any other suitable HTTP status code which does not imply the resource exists as requested\&.
126 .sp
127 If there is a repository at \fB$GIT_URL\fR, but access is not currently permitted, the server MUST respond with the \fB403\fR \fBForbidden\fR HTTP status code\&.
128 .sp
129 Servers SHOULD support both HTTP 1\&.0 and HTTP 1\&.1\&. Servers SHOULD support chunked encoding for both request and response bodies\&.
130 .sp
131 Clients SHOULD support both HTTP 1\&.0 and HTTP 1\&.1\&. Clients SHOULD support chunked encoding for both request and response bodies\&.
132 .sp
133 Servers MAY return ETag and/or Last\-Modified headers\&.
134 .sp
135 Clients MAY revalidate cached entities by including If\-Modified\-Since and/or If\-None\-Match request headers\&.
136 .sp
137 Servers MAY return \fB304\fR \fBNot\fR \fBModified\fR if the relevant headers appear in the request and the entity has not changed\&. Clients MUST treat \fB304\fR \fBNot\fR \fBModified\fR identical to \fB200\fR \fBOK\fR by reusing the cached entity\&.
138 .sp
139 Clients MAY reuse a cached entity without revalidation if the Cache\-Control and/or Expires header permits caching\&. Clients and servers MUST follow RFC 2616 for cache controls\&.
140 .SH "DISCOVERING REFERENCES"
141 .sp
142 All HTTP clients MUST begin either a fetch or a push exchange by discovering the references available on the remote repository\&.
143 .SS "Dumb Clients"
144 .sp
145 HTTP clients that only support the "dumb" protocol MUST discover references by making a request for the special info/refs file of the repository\&.
146 .sp
147 Dumb HTTP clients MUST make a \fBGET\fR request to \fB$GIT_URL/info/refs\fR, without any search/query parameters\&.
148 .sp
149 .if n \{\
150 .RS 4
151 .\}
152 .nf
153 C: GET $GIT_URL/info/refs HTTP/1\&.0
154 .fi
155 .if n \{\
156 .RE
157 .\}
158 .sp
159 .if n \{\
160 .RS 4
161 .\}
162 .nf
163 S: 200 OK
164 S:
165 S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
166 S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
167 S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0
168 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{}
169 .fi
170 .if n \{\
171 .RE
172 .\}
173 .sp
174 The Content\-Type of the returned info/refs entity SHOULD be \fBtext/plain\fR; \fBcharset=utf\-8\fR, but MAY be any content type\&. Clients MUST NOT attempt to validate the returned Content\-Type\&. Dumb servers MUST NOT return a return type starting with \fBapplication/x\-git\-\fR\&.
175 .sp
176 Cache\-Control headers MAY be returned to disable caching of the returned entity\&.
177 .sp
178 When examining the response clients SHOULD only examine the HTTP status code\&. Valid responses are \fB200\fR \fBOK\fR, or \fB304\fR \fBNot\fR \fBModified\fR\&.
179 .sp
180 The returned content is a UNIX formatted text file describing each ref and its known value\&. The file SHOULD be sorted by name according to the C locale ordering\&. The file SHOULD NOT include the default ref named \fBHEAD\fR\&.
181 .sp
182 .if n \{\
183 .RS 4
184 .\}
185 .nf
186 info_refs = *( ref_record )
187 ref_record = any_ref / peeled_ref
188 .fi
189 .if n \{\
190 .RE
191 .\}
192 .sp
193 .if n \{\
194 .RS 4
195 .\}
196 .nf
197 any_ref = obj\-id HTAB refname LF
198 peeled_ref = obj\-id HTAB refname LF
199 obj\-id HTAB refname "^{}" LF
200 .fi
201 .if n \{\
202 .RE
203 .\}
204 .SS "Smart Clients"
205 .sp
206 HTTP clients that support the "smart" protocol (or both the "smart" and "dumb" protocols) MUST discover references by making a parameterized request for the info/refs file of the repository\&.
207 .sp
208 The request MUST contain exactly one query parameter, \fBservice=$servicename\fR, where \fB$servicename\fR MUST be the service name the client wishes to contact to complete the operation\&. The request MUST NOT contain additional query parameters\&.
209 .sp
210 .if n \{\
211 .RS 4
212 .\}
213 .nf
214 C: GET $GIT_URL/info/refs?service=git\-upload\-pack HTTP/1\&.0
215 .fi
216 .if n \{\
217 .RE
218 .\}
219 .sp
220 dumb server reply:
221 .sp
222 .if n \{\
223 .RS 4
224 .\}
225 .nf
226 S: 200 OK
227 S:
228 S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
229 S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
230 S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0
231 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{}
232 .fi
233 .if n \{\
234 .RE
235 .\}
236 .sp
237 smart server reply:
238 .sp
239 .if n \{\
240 .RS 4
241 .\}
242 .nf
243 S: 200 OK
244 S: Content\-Type: application/x\-git\-upload\-pack\-advertisement
245 S: Cache\-Control: no\-cache
246 S:
247 S: 001e# service=git\-upload\-pack\en
248 S: 0000
249 S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\e0multi_ack\en
250 S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\en
251 S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1\&.0\en
252 S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1\&.0^{}\en
253 S: 0000
254 .fi
255 .if n \{\
256 .RE
257 .\}
258 .sp
259 The client may send Extra Parameters (see \fBgitprotocol-pack\fR(5)) as a colon\-separated string in the Git\-Protocol HTTP header\&.
260 .sp
261 Uses the \fB\-\-http\-backend\-info\-refs\fR option to \fBgit-upload-pack\fR(1)\&.
262 .sp
263 .it 1 an-trap
264 .nr an-no-space-flag 1
265 .nr an-break-flag 1
266 .br
267 .ps +1
268 \fBDumb Server Response\fR
269 .RS 4
270 .sp
271 Dumb servers MUST respond with the dumb server reply format\&.
272 .sp
273 See the prior section under dumb clients for a more detailed description of the dumb server response\&.
274 .RE
275 .sp
276 .it 1 an-trap
277 .nr an-no-space-flag 1
278 .nr an-break-flag 1
279 .br
280 .ps +1
281 \fBSmart Server Response\fR
282 .RS 4
283 .sp
284 If the server does not recognize the requested service name, or the requested service name has been disabled by the server administrator, the server MUST respond with the \fB403\fR \fBForbidden\fR HTTP status code\&.
285 .sp
286 Otherwise, smart servers MUST respond with the smart server reply format for the requested service name\&.
287 .sp
288 Cache\-Control headers SHOULD be used to disable caching of the returned entity\&.
289 .sp
290 The Content\-Type MUST be \fBapplication/x\-$servicename\-advertisement\fR\&. Clients SHOULD fall back to the dumb protocol if another content type is returned\&. When falling back to the dumb protocol clients SHOULD NOT make an additional request to \fB$GIT_URL/info/refs\fR, but instead SHOULD use the response already in hand\&. Clients MUST NOT continue if they do not support the dumb protocol\&.
291 .sp
292 Clients MUST validate the status code is either \fB200\fR \fBOK\fR or \fB304\fR \fBNot\fR \fBModified\fR\&.
293 .sp
294 Clients MUST validate the first five bytes of the response entity matches the regex \fB^\fR[\fB0\-9a\-f\fR]{4}#\&. If this test fails, clients MUST NOT continue\&.
295 .sp
296 Clients MUST parse the entire response as a sequence of pkt\-line records\&.
297 .sp
298 Clients MUST verify the first pkt\-line is # \fBservice=$servicename\fR\&. Servers MUST set $servicename to be the request parameter value\&. Servers SHOULD include an LF at the end of this line\&. Clients MUST ignore an LF at the end of the line\&.
299 .sp
300 Servers MUST terminate the response with the magic \fB0000\fR end pkt\-line marker\&.
301 .sp
302 The returned response is a pkt\-line stream describing each ref and its known value\&. The stream SHOULD be sorted by name according to the C locale ordering\&. The stream SHOULD include the default ref named \fBHEAD\fR as the first ref\&. The stream MUST include capability declarations behind a NUL on the first ref\&.
303 .sp
304 The returned response contains "version 1" if "version=1" was sent as an Extra Parameter\&.
305 .sp
306 .if n \{\
307 .RS 4
308 .\}
309 .nf
310 smart_reply = PKT\-LINE("# service=$servicename" LF)
311 "0000"
312 *1("version 1")
313 ref_list
314 "0000"
315 ref_list = empty_list / non_empty_list
316 .fi
317 .if n \{\
318 .RE
319 .\}
320 .sp
321 .if n \{\
322 .RS 4
323 .\}
324 .nf
325 empty_list = PKT\-LINE(zero\-id SP "capabilities^{}" NUL cap\-list LF)
326 .fi
327 .if n \{\
328 .RE
329 .\}
330 .sp
331 .if n \{\
332 .RS 4
333 .\}
334 .nf
335 non_empty_list = PKT\-LINE(obj\-id SP name NUL cap_list LF)
336 *ref_record
337 .fi
338 .if n \{\
339 .RE
340 .\}
341 .sp
342 .if n \{\
343 .RS 4
344 .\}
345 .nf
346 cap\-list = capability *(SP capability)
347 capability = 1*(LC_ALPHA / DIGIT / "\-" / "_")
348 LC_ALPHA = %x61\-7A
349 .fi
350 .if n \{\
351 .RE
352 .\}
353 .sp
354 .if n \{\
355 .RS 4
356 .\}
357 .nf
358 ref_record = any_ref / peeled_ref
359 any_ref = PKT\-LINE(obj\-id SP name LF)
360 peeled_ref = PKT\-LINE(obj\-id SP name LF)
361 PKT\-LINE(obj\-id SP name "^{}" LF
362 .fi
363 .if n \{\
364 .RE
365 .\}
366 .RE
367 .SH "SMART SERVICE GIT\-UPLOAD\-PACK"
368 .sp
369 This service reads from the repository pointed to by \fB$GIT_URL\fR\&.
370 .sp
371 Clients MUST first perform ref discovery with \fB$GIT_URL/info/refs\fR?service=git\-upload\-pack\&.
372 .sp
373 .if n \{\
374 .RS 4
375 .\}
376 .nf
377 C: POST $GIT_URL/git\-upload\-pack HTTP/1\&.0
378 C: Content\-Type: application/x\-git\-upload\-pack\-request
379 C:
380 C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\en
381 C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\en
382 C: 0000
383 .fi
384 .if n \{\
385 .RE
386 .\}
387 .sp
388 .if n \{\
389 .RS 4
390 .\}
391 .nf
392 S: 200 OK
393 S: Content\-Type: application/x\-git\-upload\-pack\-result
394 S: Cache\-Control: no\-cache
395 S:
396 S: \&.\&.\&.\&.ACK %s, continue
397 S: \&.\&.\&.\&.NAK
398 .fi
399 .if n \{\
400 .RE
401 .\}
402 .sp
403 Clients MUST NOT reuse or revalidate a cached response\&. Servers MUST include sufficient Cache\-Control headers to prevent caching of the response\&.
404 .sp
405 Servers SHOULD support all capabilities defined here\&.
406 .sp
407 Clients MUST send at least one "want" command in the request body\&. Clients MUST NOT reference an id in a "want" command which did not appear in the response obtained through ref discovery unless the server advertises capability \fBallow\-tip\-sha1\-in\-want\fR or \fBallow\-reachable\-sha1\-in\-want\fR\&.
408 .sp
409 .if n \{\
410 .RS 4
411 .\}
412 .nf
413 compute_request = want_list
414 have_list
415 request_end
416 request_end = "0000" / "done"
417 .fi
418 .if n \{\
419 .RE
420 .\}
421 .sp
422 .if n \{\
423 .RS 4
424 .\}
425 .nf
426 want_list = PKT\-LINE(want SP cap_list LF)
427 *(want_pkt)
428 want_pkt = PKT\-LINE(want LF)
429 want = "want" SP id
430 cap_list = capability *(SP capability)
431 .fi
432 .if n \{\
433 .RE
434 .\}
435 .sp
436 .if n \{\
437 .RS 4
438 .\}
439 .nf
440 have_list = *PKT\-LINE("have" SP id LF)
441 .fi
442 .if n \{\
443 .RE
444 .\}
445 .sp
446 TODO: Document this further\&.
447 .SS "The Negotiation Algorithm"
448 .sp
449 The computation to select the minimal pack proceeds as follows (C = client, S = server):
450 .sp
451 \fIinit step:\fR
452 .sp
453 C: Use ref discovery to obtain the advertised refs\&.
454 .sp
455 C: Place any object seen into set \fBadvertised\fR\&.
456 .sp
457 C: Build an empty set, \fBcommon\fR, to hold the objects that are later determined to be on both ends\&.
458 .sp
459 C: Build a set, \fBwant\fR, of the objects from \fBadvertised\fR that the client wants to fetch, based on what it saw during ref discovery\&.
460 .sp
461 C: Start a queue, \fBc_pending\fR, ordered by commit time (popping newest first)\&. Add all client refs\&. When a commit is popped from the queue its parents SHOULD be automatically inserted back\&. Commits MUST only enter the queue once\&.
462 .sp
463 \fIone compute step:\fR
464 .sp
465 C: Send one \fB$GIT_URL/git\-upload\-pack\fR request:
466 .sp
467 .if n \{\
468 .RS 4
469 .\}
470 .nf
471 C: 0032want <want\-#1>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
472 C: 0032want <want\-#2>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
473 \&.\&.\&.\&.
474 C: 0032have <common\-#1>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
475 C: 0032have <common\-#2>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
476 \&.\&.\&.\&.
477 C: 0032have <have\-#1>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
478 C: 0032have <have\-#2>\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.\&.
479 \&.\&.\&.\&.
480 C: 0000
481 .fi
482 .if n \{\
483 .RE
484 .\}
485 .sp
486 The stream is organized into "commands", with each command appearing by itself in a pkt\-line\&. Within a command line, the text leading up to the first space is the command name, and the remainder of the line to the first LF is the value\&. Command lines are terminated with an LF as the last byte of the pkt\-line value\&.
487 .sp
488 Commands MUST appear in the following order, if they appear at all in the request stream:
489 .sp
490 .RS 4
491 .ie n \{\
492 \h'-04'\(bu\h'+03'\c
493 .\}
494 .el \{\
495 .sp -1
496 .IP \(bu 2.3
497 .\}
498 "want"
499 .RE
500 .sp
501 .RS 4
502 .ie n \{\
503 \h'-04'\(bu\h'+03'\c
504 .\}
505 .el \{\
506 .sp -1
507 .IP \(bu 2.3
508 .\}
509 "have"
510 .RE
511 .sp
512 The stream is terminated by a pkt\-line flush (\fB0000\fR)\&.
513 .sp
514 A single "want" or "have" command MUST have one hex formatted object name as its value\&. Multiple object names MUST be sent by sending multiple commands\&. Object names MUST be given using the object format negotiated through the \fBobject\-format\fR capability (default SHA\-1)\&.
515 .sp
516 The \fBhave\fR list is created by popping the first 32 commits from \fBc_pending\fR\&. Fewer can be supplied if \fBc_pending\fR empties\&.
517 .sp
518 If the client has sent 256 "have" commits and has not yet received one of those back from \fBs_common\fR, or the client has emptied \fBc_pending\fR it SHOULD include a "done" command to let the server know it won\(cqt proceed:
519 .sp
520 .if n \{\
521 .RS 4
522 .\}
523 .nf
524 C: 0009done
525 .fi
526 .if n \{\
527 .RE
528 .\}
529 .sp
530 S: Parse the git\-upload\-pack request:
531 .sp
532 Verify all objects in \fBwant\fR are directly reachable from refs\&.
533 .sp
534 The server MAY walk backwards through history or through the reflog to permit slightly stale requests\&.
535 .sp
536 If no "want" objects are received, send an error: TODO: Define error if no "want" lines are requested\&.
537 .sp
538 If any "want" object is not reachable, send an error: TODO: Define error if an invalid "want" is requested\&.
539 .sp
540 Create an empty list, \fBs_common\fR\&.
541 .sp
542 If "have" was sent:
543 .sp
544 Loop through the objects in the order supplied by the client\&.
545 .sp
546 For each object, if the server has the object reachable from a ref, add it to \fBs_common\fR\&. If a commit is added to \fBs_common\fR, do not add any ancestors, even if they also appear in \fBhave\fR\&.
547 .sp
548 S: Send the git\-upload\-pack response:
549 .sp
550 If the server has found a closed set of objects to pack or the request ends with "done", it replies with the pack\&. TODO: Document the pack based response
551 .sp
552 .if n \{\
553 .RS 4
554 .\}
555 .nf
556 S: PACK\&.\&.\&.
557 .fi
558 .if n \{\
559 .RE
560 .\}
561 .sp
562 The returned stream is the side\-band\-64k protocol supported by the git\-upload\-pack service, and the pack is embedded into stream 1\&. Progress messages from the server side MAY appear in stream 2\&.
563 .sp
564 Here a "closed set of objects" is defined to have at least one path from every "want" to at least one "common" object\&.
565 .sp
566 If the server needs more information, it replies with a status continue response: TODO: Document the non\-pack response
567 .sp
568 C: Parse the upload\-pack response: TODO: Document parsing response
569 .sp
570 \fIDo another compute step\&.\fR
571 .SH "SMART SERVICE GIT\-RECEIVE\-PACK"
572 .sp
573 This service reads from the repository pointed to by \fB$GIT_URL\fR\&.
574 .sp
575 Clients MUST first perform ref discovery with \fB$GIT_URL/info/refs\fR?service=git\-receive\-pack\&.
576 .sp
577 .if n \{\
578 .RS 4
579 .\}
580 .nf
581 C: POST $GIT_URL/git\-receive\-pack HTTP/1\&.0
582 C: Content\-Type: application/x\-git\-receive\-pack\-request
583 C:
584 C: \&.\&.\&.\&.0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\e0 report\-status
585 C: 0000
586 C: PACK\&.\&.\&.\&.
587 .fi
588 .if n \{\
589 .RE
590 .\}
591 .sp
592 .if n \{\
593 .RS 4
594 .\}
595 .nf
596 S: 200 OK
597 S: Content\-Type: application/x\-git\-receive\-pack\-result
598 S: Cache\-Control: no\-cache
599 S:
600 S: \&.\&.\&.\&.
601 .fi
602 .if n \{\
603 .RE
604 .\}
605 .sp
606 Clients MUST NOT reuse or revalidate a cached response\&. Servers MUST include sufficient Cache\-Control headers to prevent caching of the response\&.
607 .sp
608 Servers SHOULD support all capabilities defined here\&.
609 .sp
610 Clients MUST send at least one command in the request body\&. Within the command portion of the request body clients SHOULD send the id obtained through ref discovery as old_id\&.
611 .sp
612 .if n \{\
613 .RS 4
614 .\}
615 .nf
616 update_request = command_list
617 "PACK" <binary\-data>
618 .fi
619 .if n \{\
620 .RE
621 .\}
622 .sp
623 .if n \{\
624 .RS 4
625 .\}
626 .nf
627 command_list = PKT\-LINE(command NUL cap_list LF)
628 *(command_pkt)
629 command_pkt = PKT\-LINE(command LF)
630 cap_list = *(SP capability) SP
631 .fi
632 .if n \{\
633 .RE
634 .\}
635 .sp
636 .if n \{\
637 .RS 4
638 .\}
639 .nf
640 command = create / delete / update
641 create = zero\-id SP new_id SP name
642 delete = old_id SP zero\-id SP name
643 update = old_id SP new_id SP name
644 .fi
645 .if n \{\
646 .RE
647 .\}
648 .sp
649 TODO: Document this further\&.
650 .SH "REFERENCES"
651 .sp
652 \m[blue]\fBRFC 1738: Uniform Resource Locators (URL)\fR\m[]\&\s-2\u[1]\d\s+2 \m[blue]\fBRFC 2616: Hypertext Transfer Protocol \(em HTTP/1\&.1\fR\m[]\&\s-2\u[2]\d\s+2
653 .SH "SEE ALSO"
654 .sp
655 \fBgitprotocol-pack\fR(5) \fBgitprotocol-capabilities\fR(5)
656 .SH "GIT"
657 .sp
658 Part of the \fBgit\fR(1) suite
659 .SH "NOTES"
660 .IP " 1." 4
661 RFC 1738: Uniform Resource Locators (URL)
662 .RS 4
663 \%https://www.ietf.org/rfc/rfc1738.txt
664 .RE
665 .IP " 2." 4
666 RFC 2616: Hypertext Transfer Protocol \(em HTTP/1.1
667 .RS 4
668 \%https://www.ietf.org/rfc/rfc2616.txt
669 .RE