[RFC/PATCH 5/5] WIP/Document the http protocol change
From: Stefan Beller <hidden>
Date: 2016-06-15 23:03:56
Subsystem:
documentation, the rest · Maintainers:
Jonathan Corbet, Linus Torvalds
Signed-off-by: Stefan Beller <redacted> --- Documentation/technical/http-protocol.txt | 4 ++-- Documentation/technical/protocol-capabilities.txt | 4 ++++ 2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 229f845..638819d 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt@@ -191,10 +191,10 @@ HTTP clients that support the "smart" protocol (or both the "smart" and "dumb" protocols) MUST discover references by making a parameterized request for the info/refs file of the repository. -The request MUST contain exactly one query parameter, +The request MAY contain parameters. Supported parameters includes `service=$servicename`, where `$servicename` MUST be the service name the client wishes to contact to complete the operation. -The request MUST NOT contain additional query parameters. +Further parameters are as described in protocol-capabilities.txt C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index 4f8a7bf..40ddb37 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt@@ -3,6 +3,10 @@ Git Protocol Capabilities Servers SHOULD support all capabilities defined in this document. +The client MAY ask for capabilities first out of band to the server. +If so the server MUST NOT advertise any capabilities the client did +not ask for. + On the very first line of the initial server response of either receive-pack and upload-pack the first reference is followed by a NUL byte and then a list of space delimited server capabilities.
--
2.3.0.81.gc37f363