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@xxxxxxxxx>
--
pkt-line format section was dropped in response to Junio's comments:
From: Junio C Hamano <gitster@xxxxxxxxx>
Message-ID: <7vskdss3ei.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
> +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@xxxxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html