From: Tay Ray Chuan <rctay89@gmail.com>
To: "Git Mailing List" <git@vger.kernel.org>
Cc: "Junio C Hamano" <gitster@pobox.com>
Subject: [PATCH 02/14] normalize indentation with protcol-common.txt
Date: Wed, 11 Sep 2013 01:07:46 +0800 [thread overview]
Message-ID: <1378832878-12811-3-git-send-email-rctay89@gmail.com> (raw)
In-Reply-To: <1378832878-12811-2-git-send-email-rctay89@gmail.com>
Indent client/server query examples with 3 spaces.
Indent ABNF rules with 2 spaces.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
--
This is in its own patch to minimize noise in diffs.
---
Documentation/technical/http-protocol.txt | 226 +++++++++++++++---------------
1 file changed, 113 insertions(+), 113 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 0a2a53d..70a1648 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -161,14 +161,14 @@ Dumb HTTP clients MUST NOT include search/query parameters when
fetching the info/refs file. (That is, '?' must not appear in the
requested URL.)
- C: GET $GIT_URL/info/refs HTTP/1.0
+ C: GET $GIT_URL/info/refs HTTP/1.0
- S: 200 OK
- S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
The Content-Type of the returned info/refs entity SHOULD be
"text/plain; charset=utf-8", but MAY be any content type.
@@ -187,17 +187,17 @@ 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 'HEAD'.
- info_refs = *( ref_record )
- ref_record = any_ref | peeled_ref
+ info_refs = *( ref_record )
+ ref_record = any_ref | peeled_ref
- any_ref = id HT name LF
- peeled_ref = id HT name LF
- id HT name "^{}" LF
- id = 40*HEX
+ any_ref = id HT name LF
+ peeled_ref = id HT name LF
+ id HT name "^{}" LF
+ id = 40*HEX
- HEX = "0".."9" | "a".."f"
- LF = <US-ASCII LF, linefeed (10)>
- HT = <US-ASCII HT, horizontal-tab (9)>
+ HEX = "0".."9" | "a".."f"
+ LF = <US-ASCII LF, linefeed (10)>
+ HT = <US-ASCII HT, horizontal-tab (9)>
Smart Clients
~~~~~~~~~~~~~
@@ -211,26 +211,26 @@ The request MUST contain exactly one query parameter,
name the client wishes to contact to complete the operation.
The request MUST NOT contain additional query parameters.
- C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
-
- dumb server reply:
- S: 200 OK
- S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
-
- smart server reply:
- S: 200 OK
- S: Content-Type: application/x-git-upload-pack-advertisement
- S: Cache-Control: no-cache
- S:
- S: ....# service=git-upload-pack
- S: ....95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
- S: ....d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: ....2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: ....a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
+
+ dumb server reply:
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+
+ smart server reply:
+ S: 200 OK
+ S: Content-Type: application/x-git-upload-pack-advertisement
+ S: Cache-Control: no-cache
+ S:
+ S: ....# service=git-upload-pack
+ S: ....95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
+ S: ....d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: ....2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: ....a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
Dumb Server Response
^^^^^^^^^^^^^^^^^^^^
@@ -281,28 +281,28 @@ the C locale ordering. The stream SHOULD include the default ref
named 'HEAD' as the first ref. The stream MUST include capability
declarations behind a NUL on the first ref.
- smart_reply = PKT-LINE("# service=$servicename" LF)
- ref_list
- "0000"
- ref_list = empty_list | non_empty_list
+ smart_reply = PKT-LINE("# service=$servicename" LF)
+ ref_list
+ "0000"
+ ref_list = empty_list | non_empty_list
- empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
+ empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
- non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
- *ref_record
+ non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
+ *ref_record
- cap_list = *(SP capability) SP
- ref_record = any_ref | peeled_ref
+ cap_list = *(SP capability) SP
+ ref_record = any_ref | peeled_ref
- any_ref = PKT-LINE(id SP name LF)
- peeled_ref = PKT-LINE(id SP name LF)
- PKT-LINE(id SP name "^{}" LF
- id = 40*HEX
+ any_ref = PKT-LINE(id SP name LF)
+ peeled_ref = PKT-LINE(id SP name LF)
+ PKT-LINE(id SP name "^{}" LF
+ id = 40*HEX
- HEX = "0".."9" | "a".."f"
- NL = <US-ASCII NUL, null (0)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, horizontal-tab (9)>
+ HEX = "0".."9" | "a".."f"
+ NL = <US-ASCII NUL, null (0)>
+ LF = <US-ASCII LF, linefeed (10)>
+ SP = <US-ASCII SP, horizontal-tab (9)>
Smart Service git-upload-pack
@@ -312,19 +312,19 @@ This service reads from the remote repository.
Clients MUST first perform ref discovery with
'$GIT_URL/info/refs?service=git-upload-pack'.
- C: POST $GIT_URL/git-upload-pack HTTP/1.0
- C: Content-Type: application/x-git-upload-pack-request
- C:
- C: ....want 0a53e9ddeaddad63ad106860237bbf53411d11a7
- C: ....have 441b40d833fdfa93eb2908e52742248faf0ee993
- C: 0000
+ C: POST $GIT_URL/git-upload-pack HTTP/1.0
+ C: Content-Type: application/x-git-upload-pack-request
+ C:
+ C: ....want 0a53e9ddeaddad63ad106860237bbf53411d11a7
+ C: ....have 441b40d833fdfa93eb2908e52742248faf0ee993
+ C: 0000
- S: 200 OK
- S: Content-Type: application/x-git-upload-pack-result
- S: Cache-Control: no-cache
- S:
- S: ....ACK %s, continue
- S: ....NAK
+ S: 200 OK
+ S: Content-Type: application/x-git-upload-pack-result
+ S: Cache-Control: no-cache
+ S:
+ S: ....ACK %s, continue
+ S: ....NAK
Clients MUST NOT reuse or revalidate a cached reponse.
Servers MUST include sufficient Cache-Control headers
@@ -336,23 +336,23 @@ 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.
- compute_request = want_list
- have_list
- request_end
- request_end = "0000" | "done"
+ compute_request = want_list
+ have_list
+ request_end
+ request_end = "0000" | "done"
- want_list = PKT-LINE(want NUL cap_list LF)
- *(want_pkt)
- want_pkt = PKT-LINE(want LF)
- want = "want" SP id
- cap_list = *(SP capability) SP
+ want_list = PKT-LINE(want NUL cap_list LF)
+ *(want_pkt)
+ want_pkt = PKT-LINE(want LF)
+ want = "want" SP id
+ cap_list = *(SP capability) SP
- have_list = *PKT-LINE("have" SP id LF)
+ have_list = *PKT-LINE("have" SP id LF)
- command = create | delete | update
- create = 40*"0" SP new_id SP name
- delete = old_id SP 40*"0" SP name
- update = old_id SP new_id SP name
+ command = create | delete | update
+ create = 40*"0" SP new_id SP name
+ delete = old_id SP 40*"0" SP name
+ update = old_id SP new_id SP name
TODO: Document this further.
TODO: Don't use uppercase for variable names below.
@@ -396,16 +396,16 @@ The computation to select the minimal pack proceeds as follows
one compute step:
(c) Send one $GIT_URL/git-upload-pack request:
- C: 0032want <WANT #1>...............................
- C: 0032want <WANT #2>...............................
- ....
- C: 0032have <COMMON #1>.............................
- C: 0032have <COMMON #2>.............................
- ....
- C: 0032have <HAVE #1>...............................
- C: 0032have <HAVE #2>...............................
- ....
- C: 0000
+ C: 0032want <WANT #1>...............................
+ C: 0032want <WANT #2>...............................
+ ....
+ C: 0032have <COMMON #1>.............................
+ C: 0032have <COMMON #2>.............................
+ ....
+ C: 0032have <HAVE #1>...............................
+ C: 0032have <HAVE #2>...............................
+ ....
+ C: 0000
The stream is organized into "commands", with each command
appearing by itself in a pkt-line. Within a command line
@@ -434,13 +434,13 @@ The computation to select the minimal pack proceeds as follows
emptied C_PENDING it should include a "done" command to let
the server know it won't proceed:
- C: 0009done
+ C: 0009done
(s) Parse the git-upload-pack request:
Verify all objects in WANT are directly reachable from refs.
- The server MAY walk backwards through history or through
+ The server MAY walk backwards through history or through
the reflog to permit slightly stale requests.
If no WANT objects are received, send an error:
@@ -466,7 +466,7 @@ TODO: Define error if an invalid want is requested.
request ends with "done", it replies with the pack.
TODO: Document the pack based response
- S: PACK...
+ S: PACK...
The returned stream is the side-band-64k protocol supported
by the git-upload-pack service, and the pack is embedded into
@@ -495,18 +495,18 @@ This service modifies the remote repository.
Clients MUST first perform ref discovery with
'$GIT_URL/info/refs?service=git-receive-pack'.
- C: POST $GIT_URL/git-receive-pack HTTP/1.0
- C: Content-Type: application/x-git-receive-pack-request
- C:
- C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
- C: 0000
- C: PACK....
+ C: POST $GIT_URL/git-receive-pack HTTP/1.0
+ C: Content-Type: application/x-git-receive-pack-request
+ C:
+ C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
+ C: 0000
+ C: PACK....
- S: 200 OK
- S: Content-Type: application/x-git-receive-pack-result
- S: Cache-Control: no-cache
- S:
- S: ....
+ S: 200 OK
+ S: Content-Type: application/x-git-receive-pack-result
+ S: Cache-Control: no-cache
+ S:
+ S: ....
Clients MUST NOT reuse or revalidate a cached reponse.
Servers MUST include sufficient Cache-Control headers
@@ -518,18 +518,18 @@ 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.
- update_request = command_list
- "PACK" <binary data>
+ update_request = command_list
+ "PACK" <binary data>
- command_list = PKT-LINE(command NUL cap_list LF)
- *(command_pkt)
- command_pkt = PKT-LINE(command LF)
- cap_list = *(SP capability) SP
+ command_list = PKT-LINE(command NUL cap_list LF)
+ *(command_pkt)
+ command_pkt = PKT-LINE(command LF)
+ cap_list = *(SP capability) SP
- command = create | delete | update
- create = 40*"0" SP new_id SP name
- delete = old_id SP 40*"0" SP name
- update = old_id SP new_id SP name
+ command = create | delete | update
+ create = 40*"0" SP new_id SP name
+ delete = old_id SP 40*"0" SP name
+ update = old_id SP new_id SP name
TODO: Document this further.
--
1.8.4.rc4.527.g303b16c
next prev parent reply other threads:[~2013-09-10 17:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 5:22 [RFC PATCH 0/4] Return of smart HTTP Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 1/4] Document the HTTP transport protocol Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 2/4] Git-aware CGI to provide dumb HTTP transport Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 3/4] Add smart-http options to upload-pack, receive-pack Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 4/4] Smart fetch and push over HTTP: server side Shawn O. Pearce
2009-10-09 5:52 ` [RFC PATCH 2/4] Git-aware CGI to provide dumb HTTP transport J.H.
2009-10-09 8:01 ` [RFC PATCH 1/4] Document the HTTP transport protocol Sverre Rabbelier
2009-10-09 8:09 ` Sverre Rabbelier
2009-10-09 8:54 ` Alex Blewitt
2009-10-15 16:39 ` Shawn O. Pearce
2009-10-09 19:27 ` Jakub Narebski
2009-10-09 19:50 ` Jeff King
2009-10-15 16:52 ` Shawn O. Pearce
2009-10-15 17:39 ` Jeff King
2009-10-09 20:44 ` Junio C Hamano
2009-10-10 10:12 ` Antti-Juhani Kaijanaho
2009-10-16 5:59 ` H. Peter Anvin
2009-10-16 7:19 ` Mike Hommey
2009-10-16 14:21 ` Shawn O. Pearce
2009-10-16 14:23 ` Antti-Juhani Kaijanaho
2010-04-07 18:16 ` Tay Ray Chuan
2010-04-07 18:19 ` Tay Ray Chuan
2010-04-07 19:11 ` (resend v2) " Tay Ray Chuan
2010-04-07 19:51 ` Junio C Hamano
2010-04-08 1:47 ` Tay Ray Chuan
2010-04-07 19:24 ` Tay Ray Chuan
2009-10-10 12:17 ` Tay Ray Chuan
2010-04-06 4:57 ` Scott Chacon
2010-04-06 6:09 ` Junio C Hamano
[not found] ` <u2hd411cc4a1004060652k5a7f8ea4l67a9b079963f4dc4@mail.gmail.com>
2010-04-06 13:53 ` Scott Chacon
2010-04-06 17:26 ` Junio C Hamano
2013-09-10 17:07 ` [PATCH 00/14] document edits to original http protocol documentation Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 01/14] Document the HTTP transport protocol Tay Ray Chuan
2013-09-10 17:07 ` Tay Ray Chuan [this message]
2013-09-10 17:07 ` [PATCH 03/14] capitalize key words according to RFC 2119 Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 04/14] normalize rules with RFC 5234 Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 05/14] drop rules, etc. common to the pack protocol Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 06/14] reword behaviour on missing repository or objects Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 07/14] weaken specification over cookies for authentication Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 08/14] mention different variations around $GIT_URL Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 10/14] fix example request/responses Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 11/14] be clearer in place of 'remote repository' phrase Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 12/14] reduce confusion over smart server response behaviour Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 13/14] shift dumb server response details Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 14/14] mention effect of "allow-tip-sha1-in-want" capability on git-upload-pack Tay Ray Chuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1378832878-12811-3-git-send-email-rctay89@gmail.com \
--to=rctay89@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).