git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 05/14] drop rules, etc. common to the pack protocol

From
Tay Ray Chuan <rctay89@gmail.com>
Date
Sep 10, 2013, 17:07 UTC
Message-ID
<1378832878-12811-6-git-send-email-rctay89@gmail.com>
In-Reply-To
<1378832878-12811-5-git-send-email-rctay89@gmail.com>
Use obj-id in lieu of id (defined as 40*HEX).
Use zero-id in lieu of 40*"0".
Use refname in lieu of name (not defined).

Drop section on capabilities, since they are already available in protocol-capabilities.txt.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
--
pkt-line format section was dropped in response to Junio's comments:
  From:   Junio C Hamano <gitster@pobox.com>
  Message-ID: <7vskdss3ei.fsf@alter.siamese.dyndns.org>
  > +pkt-line Format
  > +---------------
  > ...
  > +Examples (as C-style strings):
  > +
  > +  pkt-line          actual value
  > +  ---------------------------------
  > +  "0006a\n"         "a\n"
  > +  "0005a"           "a"
  > +  "000bfoobar\n"    "foobar\n"
  > +  "0004"            ""
  > +
  > +A pkt-line with a length of 0 ("0000") is a special case and MUST
  > +be treated as a message break or terminator in the payload.
  Isn't this "MUST be" wrong?
  It is not an advice to the implementors, but the protocol specification
  itself defines what the flush packet means.  IOW, "The author of this
  specification, Shawn, MUST treat a flush packet as a message break or
  terminator in the payload, when designing this protocol."

Capabilities and 'command' ABNF rules under git-upload-pack were dropped by Nguyễn:

  Message-ID: <1377092713-25434-1-git-send-email-pclouds@gmail.com>
---
 Documentation/technical/http-protocol.txt | 85 ++++---------------------------
 1 file changed, 10 insertions(+), 75 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index ff91bb0..a8d28ba 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -84,34 +84,6 @@ as described by RFC 2616 (HTTP/1.1).  Servers SHOULD ignore any
 cookies sent by a client.
 
 
-pkt-line Format
----------------
-
-Much (but not all) of the payload is described around pkt-lines.
-
-A pkt-line is a variable length binary string.  The first four bytes
-of the line indicates the total length of the line, in hexadecimal.
-The total length includes the 4 bytes used to denote the length.
-A line SHOULD BE terminated by an LF, which if present MUST be
-included in the total length.
-
-A pkt-line MAY contain binary data, so implementors MUST ensure all
-pkt-line parsing/formatting routines are 8-bit clean.  The maximum
-length of a pkt-line's data is 65532 bytes (65536 - 4).
-
-Examples (as C-style strings):
-
-  pkt-line          actual value
-  ---------------------------------
-  "0006a\n"         "a\n"
-  "0005a"           "a"
-  "000bfoobar\n"    "foobar\n"
-  "0004"            ""
-
-A pkt-line with a length of 0 ("0000") is a special case and MUST
-be treated as a message break or terminator in the payload.
-
-
 General Request Processing
 --------------------------
 
@@ -194,11 +166,9 @@ the default ref named 'HEAD'.
   info_refs        =  *( ref_record )
   ref_record       =  any_ref / peeled_ref
 
-  any_ref          =  id HTAB name LF
-  peeled_ref       =  id HTAB name LF
-		      id HTAB name "^{}" LF
-  id               =  40*HEX
-
+  any_ref          =  obj-id HTAB refname LF
+  peeled_ref       =  obj-id HTAB refname LF
+		      obj-id HTAB refname "^{}" LF
 
 Smart Clients
 ~~~~~~~~~~~~~
@@ -283,23 +253,7 @@ 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
-
-  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
-
-  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
-
+		      advertised-refs
 
 Smart Service git-upload-pack
 ------------------------------
@@ -345,31 +299,9 @@ appear in the response obtained through ref discovery.
 
   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
-
 TODO: Document this further.
 TODO: Don't use uppercase for variable names below.
 
-Capability include-tag
-~~~~~~~~~~~~~~~~~~~~~~
-
-When packing an object that an annotated tag points at, include the
-tag object too.  Clients can request this if they want to fetch
-tags, but don't know which tags they will need until after they
-receive the branch data.  By enabling include-tag an entire call
-to upload-pack can be avoided.
-
-Capability thin-pack
-~~~~~~~~~~~~~~~~~~~~
-
-When packing a deltified object the base is not included if the base
-is reachable from an object listed in the COMMON set by the client.
-This reduces the bandwidth required to transfer, but it does slightly
-increase processing time for the client to save the pack to disk.
-
 The Negotiation Algorithm
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 The computation to select the minimal pack proceeds as follows
@@ -523,9 +455,9 @@ the id obtained through ref discovery as old_id.
   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
+  create           =  zero-id SP new_id SP refname
+  delete           =  old_id SP zero-id SP refname
+  update           =  old_id SP new_id SP refname
 
 TODO: Document this further.
 
@@ -536,4 +468,7 @@ References
 link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
 link:http://www.ietf.org/rfc/rfc2119.txt[RFC 2119: Key words for use in RFCs to Indicate Requirement Levels]
 link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
+link:technical/pack-protocol.txt
+link:technical/protocol-common.txt
+link:technical/protocol-capabilities.txt
 

-- 
1.8.4.rc4.527.g303b16c
Previous: Tay Ray ChuanNext: Tay Ray Chuan
Message 35 of 46 in “Return of smart HTTP”
  1. 0/4 Return of smart HTTPShawn O. Pearce, Oct 9, 2009
  2. 1/4 Document the HTTP transport protocolShawn O. Pearce, Oct 9, 2009
  3. 2/4 Git-aware CGI to provide dumb HTTP transportShawn O. Pearce, Oct 9, 2009
  4. 3/4 Add smart-http options to upload-pack, receive-packShawn O. Pearce, Oct 9, 2009
  5. 4/4 Smart fetch and push over HTTP: server sideShawn O. Pearce, Oct 9, 2009
  6. J.H.Oct 9, 2009
  7. Sverre RabbelierOct 9, 2009
  8. Sverre RabbelierOct 9, 2009
  9. Alex BlewittOct 9, 2009
  10. Shawn O. PearceOct 15, 2009
  11. Jakub NarebskiOct 9, 2009
  12. Jeff KingOct 9, 2009
  13. Shawn O. PearceOct 15, 2009
  14. Jeff KingOct 15, 2009
  15. Junio C HamanoOct 9, 2009
  16. Antti-Juhani KaijanahoOct 10, 2009
  17. H. Peter AnvinOct 16, 2009
  18. Mike HommeyOct 16, 2009
  19. Shawn O. PearceOct 16, 2009
  20. Antti-Juhani KaijanahoOct 16, 2009
  21. Tay Ray ChuanApr 7, 2010
  22. Tay Ray ChuanApr 7, 2010
  23. (resend v2) Re: [RFC PATCH 1/4] Document the HTTP transport protocolTay Ray Chuan, Apr 7, 2010
  24. Junio C HamanoApr 7, 2010
  25. Tay Ray ChuanApr 8, 2010
  26. (resend v2) Re: [RFC PATCH 1/4] Document the HTTP transport protocolTay Ray Chuan, Apr 7, 2010
  27. Tay Ray ChuanOct 10, 2009
  28. Scott ChaconApr 6, 2010
  29. Junio C HamanoApr 6, 2010
  30. 00/14 document edits to original http protocol documentationTay Ray Chuan, Sep 10, 2013
  31. 01/14 Document the HTTP transport protocolTay Ray Chuan, Sep 10, 2013
  32. 02/14 normalize indentation with protcol-common.txtTay Ray Chuan, Sep 10, 2013
  33. 03/14 capitalize key words according to RFC 2119Tay Ray Chuan, Sep 10, 2013
  34. 04/14 normalize rules with RFC 5234Tay Ray Chuan, Sep 10, 2013
  35. 05/14 drop rules, etc. common to the pack protocolTay Ray Chuan, Sep 10, 2013
  36. 06/14 reword behaviour on missing repository or objectsTay Ray Chuan, Sep 10, 2013
  37. 07/14 weaken specification over cookies for authenticationTay Ray Chuan, Sep 10, 2013
  38. 08/14 mention different variations around $GIT_URLTay Ray Chuan, Sep 10, 2013
  39. 09/14 reduce ambiguity over '?' in $GIT_URL for dumb clientsTay Ray Chuan, Sep 10, 2013
  40. 10/14 fix example request/responsesTay Ray Chuan, Sep 10, 2013
  41. 11/14 be clearer in place of 'remote repository' phraseTay Ray Chuan, Sep 10, 2013
  42. 12/14 reduce confusion over smart server response behaviourTay Ray Chuan, Sep 10, 2013
  43. 13/14 shift dumb server response detailsTay Ray Chuan, Sep 10, 2013
  44. 14/14 mention effect of "allow-tip-sha1-in-want" capability on git-upload-packTay Ray Chuan, Sep 10, 2013
  45. 1/4 Document the HTTP transport protocolScott Chacon, Apr 6, 2010
  46. Junio C HamanoApr 6, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.