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