]>
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 | ||
63 | Clients SHOULD support Basic authentication as described by RFC 2616. | |
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 | |
217 | S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n | |
218 | S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n | |
219 | S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n | |
220 | S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n | |
221 | ||
222 | Dumb Server Response | |
223 | ^^^^^^^^^^^^^^^^^^^^ | |
224 | Dumb servers MUST respond with the dumb server reply format. | |
225 | ||
226 | See the prior section under dumb clients for a more detailed | |
227 | description of the dumb server response. | |
228 | ||
229 | Smart Server Response | |
230 | ^^^^^^^^^^^^^^^^^^^^^ | |
231 | If the server does not recognize the requested service name, or the | |
232 | requested service name has been disabled by the server administrator, | |
586aa786 | 233 | the server MUST respond with the `403 Forbidden` HTTP status code. |
4c6fffe2 SP |
234 | |
235 | Otherwise, smart servers MUST respond with the smart server reply | |
236 | format for the requested service name. | |
237 | ||
238 | Cache-Control headers SHOULD be used to disable caching of the | |
239 | returned entity. | |
240 | ||
586aa786 | 241 | The Content-Type MUST be `application/x-$servicename-advertisement`. |
4c6fffe2 SP |
242 | Clients SHOULD fall back to the dumb protocol if another content |
243 | type is returned. When falling back to the dumb protocol clients | |
586aa786 | 244 | SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but |
4c6fffe2 SP |
245 | instead SHOULD use the response already in hand. Clients MUST NOT |
246 | continue if they do not support the dumb protocol. | |
247 | ||
586aa786 TA |
248 | Clients MUST validate the status code is either `200 OK` or |
249 | `304 Not Modified`. | |
4c6fffe2 SP |
250 | |
251 | Clients MUST validate the first five bytes of the response entity | |
586aa786 | 252 | matches the regex `^[0-9a-f]{4}#`. If this test fails, clients |
4c6fffe2 SP |
253 | MUST NOT continue. |
254 | ||
255 | Clients MUST parse the entire response as a sequence of pkt-line | |
256 | records. | |
257 | ||
586aa786 | 258 | Clients MUST verify the first pkt-line is `# service=$servicename`. |
4c6fffe2 SP |
259 | Servers MUST set $servicename to be the request parameter value. |
260 | Servers SHOULD include an LF at the end of this line. | |
261 | Clients MUST ignore an LF at the end of the line. | |
262 | ||
586aa786 | 263 | Servers MUST terminate the response with the magic `0000` end |
4c6fffe2 SP |
264 | pkt-line marker. |
265 | ||
266 | The returned response is a pkt-line stream describing each ref and | |
267 | its known value. The stream SHOULD be sorted by name according to | |
268 | the C locale ordering. The stream SHOULD include the default ref | |
586aa786 | 269 | named `HEAD` as the first ref. The stream MUST include capability |
4c6fffe2 SP |
270 | declarations behind a NUL on the first ref. |
271 | ||
272 | smart_reply = PKT-LINE("# service=$servicename" LF) | |
273 | ref_list | |
274 | "0000" | |
275 | ref_list = empty_list / non_empty_list | |
276 | ||
277 | empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF) | |
278 | ||
279 | non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF) | |
280 | *ref_record | |
281 | ||
282 | cap-list = capability *(SP capability) | |
283 | capability = 1*(LC_ALPHA / DIGIT / "-" / "_") | |
284 | LC_ALPHA = %x61-7A | |
285 | ||
286 | ref_record = any_ref / peeled_ref | |
287 | any_ref = PKT-LINE(obj-id SP name LF) | |
288 | peeled_ref = PKT-LINE(obj-id SP name LF) | |
289 | PKT-LINE(obj-id SP name "^{}" LF | |
290 | ||
586aa786 | 291 | |
4c6fffe2 SP |
292 | Smart Service git-upload-pack |
293 | ------------------------------ | |
586aa786 | 294 | This service reads from the repository pointed to by `$GIT_URL`. |
4c6fffe2 SP |
295 | |
296 | Clients MUST first perform ref discovery with | |
586aa786 | 297 | `$GIT_URL/info/refs?service=git-upload-pack`. |
4c6fffe2 SP |
298 | |
299 | C: POST $GIT_URL/git-upload-pack HTTP/1.0 | |
300 | C: Content-Type: application/x-git-upload-pack-request | |
301 | C: | |
302 | C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n | |
303 | C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n | |
304 | C: 0000 | |
305 | ||
306 | S: 200 OK | |
307 | S: Content-Type: application/x-git-upload-pack-result | |
308 | S: Cache-Control: no-cache | |
309 | S: | |
310 | S: ....ACK %s, continue | |
311 | S: ....NAK | |
312 | ||
7e7cf80d | 313 | Clients MUST NOT reuse or revalidate a cached response. |
4c6fffe2 SP |
314 | Servers MUST include sufficient Cache-Control headers |
315 | to prevent caching of the response. | |
316 | ||
317 | Servers SHOULD support all capabilities defined here. | |
318 | ||
586aa786 TA |
319 | Clients MUST send at least one "want" command in the request body. |
320 | Clients MUST NOT reference an id in a "want" command which did not | |
4c6fffe2 | 321 | appear in the response obtained through ref discovery unless the |
586aa786 | 322 | server advertises capability `allow-tip-sha1-in-want`. |
4c6fffe2 SP |
323 | |
324 | compute_request = want_list | |
325 | have_list | |
326 | request_end | |
327 | request_end = "0000" / "done" | |
328 | ||
329 | want_list = PKT-LINE(want NUL cap_list LF) | |
330 | *(want_pkt) | |
331 | want_pkt = PKT-LINE(want LF) | |
332 | want = "want" SP id | |
333 | cap_list = *(SP capability) SP | |
334 | ||
335 | have_list = *PKT-LINE("have" SP id LF) | |
336 | ||
337 | TODO: Document this further. | |
338 | TODO: Don't use uppercase for variable names below. | |
339 | ||
340 | The Negotiation Algorithm | |
341 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
342 | The computation to select the minimal pack proceeds as follows | |
586aa786 TA |
343 | (C = client, S = server): |
344 | ||
345 | 'init step:' | |
346 | ||
347 | C: Use ref discovery to obtain the advertised refs. | |
348 | ||
349 | C: Place any object seen into set ADVERTISED. | |
4c6fffe2 | 350 | |
586aa786 TA |
351 | C: Build an empty set, COMMON, to hold the objects that are later |
352 | determined to be on both ends. | |
4c6fffe2 | 353 | |
586aa786 TA |
354 | C: Build a set, WANT, of the objects from ADVERTISED the client |
355 | wants to fetch, based on what it saw during ref discovery. | |
4c6fffe2 | 356 | |
586aa786 TA |
357 | C: Start a queue, C_PENDING, ordered by commit time (popping newest |
358 | first). Add all client refs. When a commit is popped from | |
359 | the queue its parents SHOULD be automatically inserted back. | |
360 | Commits MUST only enter the queue once. | |
4c6fffe2 | 361 | |
586aa786 TA |
362 | 'one compute step:' |
363 | ||
364 | C: Send one `$GIT_URL/git-upload-pack` request: | |
4c6fffe2 SP |
365 | |
366 | C: 0032want <WANT #1>............................... | |
367 | C: 0032want <WANT #2>............................... | |
368 | .... | |
369 | C: 0032have <COMMON #1>............................. | |
370 | C: 0032have <COMMON #2>............................. | |
371 | .... | |
372 | C: 0032have <HAVE #1>............................... | |
373 | C: 0032have <HAVE #2>............................... | |
374 | .... | |
375 | C: 0000 | |
376 | ||
586aa786 TA |
377 | The stream is organized into "commands", with each command |
378 | appearing by itself in a pkt-line. Within a command line | |
379 | the text leading up to the first space is the command name, | |
380 | and the remainder of the line to the first LF is the value. | |
381 | Command lines are terminated with an LF as the last byte of | |
382 | the pkt-line value. | |
4c6fffe2 | 383 | |
586aa786 TA |
384 | Commands MUST appear in the following order, if they appear |
385 | at all in the request stream: | |
4c6fffe2 | 386 | |
586aa786 TA |
387 | * "want" |
388 | * "have" | |
4c6fffe2 | 389 | |
586aa786 | 390 | The stream is terminated by a pkt-line flush (`0000`). |
4c6fffe2 | 391 | |
586aa786 TA |
392 | A single "want" or "have" command MUST have one hex formatted |
393 | SHA-1 as its value. Multiple SHA-1s MUST be sent by sending | |
394 | multiple commands. | |
4c6fffe2 | 395 | |
586aa786 TA |
396 | The HAVE list is created by popping the first 32 commits |
397 | from C_PENDING. Less can be supplied if C_PENDING empties. | |
4c6fffe2 | 398 | |
586aa786 TA |
399 | If the client has sent 256 HAVE commits and has not yet |
400 | received one of those back from S_COMMON, or the client has | |
401 | emptied C_PENDING it SHOULD include a "done" command to let | |
402 | the server know it won't proceed: | |
4c6fffe2 SP |
403 | |
404 | C: 0009done | |
405 | ||
586aa786 | 406 | S: Parse the git-upload-pack request: |
4c6fffe2 | 407 | |
586aa786 | 408 | Verify all objects in WANT are directly reachable from refs. |
4c6fffe2 | 409 | |
586aa786 TA |
410 | The server MAY walk backwards through history or through |
411 | the reflog to permit slightly stale requests. | |
4c6fffe2 | 412 | |
586aa786 TA |
413 | If no WANT objects are received, send an error: |
414 | TODO: Define error if no "want" lines are requested. | |
4c6fffe2 | 415 | |
586aa786 TA |
416 | If any WANT object is not reachable, send an error: |
417 | TODO: Define error if an invalid "want" is requested. | |
4c6fffe2 | 418 | |
586aa786 | 419 | Create an empty list, S_COMMON. |
4c6fffe2 | 420 | |
586aa786 | 421 | If "have" was sent: |
4c6fffe2 | 422 | |
586aa786 | 423 | Loop through the objects in the order supplied by the client. |
4c6fffe2 | 424 | |
586aa786 TA |
425 | For each object, if the server has the object reachable from |
426 | a ref, add it to S_COMMON. If a commit is added to S_COMMON, | |
427 | do not add any ancestors, even if they also appear in HAVE. | |
4c6fffe2 | 428 | |
586aa786 | 429 | S: Send the git-upload-pack response: |
4c6fffe2 | 430 | |
586aa786 TA |
431 | If the server has found a closed set of objects to pack or the |
432 | request ends with "done", it replies with the pack. | |
4c6fffe2 | 433 | TODO: Document the pack based response |
4c6fffe2 | 434 | |
586aa786 | 435 | S: PACK... |
4c6fffe2 | 436 | |
586aa786 TA |
437 | The returned stream is the side-band-64k protocol supported |
438 | by the git-upload-pack service, and the pack is embedded into | |
439 | stream 1. Progress messages from the server side MAY appear | |
440 | in stream 2. | |
4c6fffe2 | 441 | |
586aa786 TA |
442 | Here a "closed set of objects" is defined to have at least |
443 | one path from every WANT to at least one COMMON object. | |
4c6fffe2 | 444 | |
586aa786 TA |
445 | If the server needs more information, it replies with a |
446 | status continue response: | |
4c6fffe2 SP |
447 | TODO: Document the non-pack response |
448 | ||
586aa786 TA |
449 | C: Parse the upload-pack response: |
450 | TODO: Document parsing response | |
4c6fffe2 | 451 | |
586aa786 | 452 | 'Do another compute step.' |
4c6fffe2 SP |
453 | |
454 | ||
455 | Smart Service git-receive-pack | |
456 | ------------------------------ | |
586aa786 | 457 | This service reads from the repository pointed to by `$GIT_URL`. |
4c6fffe2 SP |
458 | |
459 | Clients MUST first perform ref discovery with | |
586aa786 | 460 | `$GIT_URL/info/refs?service=git-receive-pack`. |
4c6fffe2 SP |
461 | |
462 | C: POST $GIT_URL/git-receive-pack HTTP/1.0 | |
463 | C: Content-Type: application/x-git-receive-pack-request | |
464 | C: | |
465 | C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status | |
466 | C: 0000 | |
467 | C: PACK.... | |
468 | ||
469 | S: 200 OK | |
470 | S: Content-Type: application/x-git-receive-pack-result | |
471 | S: Cache-Control: no-cache | |
472 | S: | |
473 | S: .... | |
474 | ||
7e7cf80d | 475 | Clients MUST NOT reuse or revalidate a cached response. |
4c6fffe2 SP |
476 | Servers MUST include sufficient Cache-Control headers |
477 | to prevent caching of the response. | |
478 | ||
479 | Servers SHOULD support all capabilities defined here. | |
480 | ||
481 | Clients MUST send at least one command in the request body. | |
482 | Within the command portion of the request body clients SHOULD send | |
483 | the id obtained through ref discovery as old_id. | |
484 | ||
485 | update_request = command_list | |
486 | "PACK" <binary data> | |
487 | ||
488 | command_list = PKT-LINE(command NUL cap_list LF) | |
489 | *(command_pkt) | |
490 | command_pkt = PKT-LINE(command LF) | |
491 | cap_list = *(SP capability) SP | |
492 | ||
493 | command = create / delete / update | |
494 | create = zero-id SP new_id SP name | |
495 | delete = old_id SP zero-id SP name | |
496 | update = old_id SP new_id SP name | |
497 | ||
498 | TODO: Document this further. | |
499 | ||
500 | ||
501 | References | |
502 | ---------- | |
503 | ||
504 | link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] | |
505 | link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] | |
d5ff3b4b SS |
506 | link:technical/pack-protocol.html |
507 | link:technical/protocol-capabilities.html |