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