path: root/Documentation/git.txt
diff options
authorShawn O. Pearce <>2009-06-05 01:33:32 (GMT)
committerJunio C Hamano <>2009-06-06 20:27:52 (GMT)
commit73bb33a94ec67a53e7d805b12ad9264fa25f4f8d (patch)
treecf0aef3b108d4c26223c530ffa80c151dcf6cd02 /Documentation/git.txt
parent6c7f58d6f691c1091b90b0891e94c91e20fd6054 (diff)
daemon: Strictly parse the "extra arg" part of the command
Since (49ba83fb67 "Add virtualization support to git-daemon") git daemon enters an infinite loop and never terminates if a client hides any extra arguments in the initial request line which is not exactly "\0host=blah\0". Since that change, a client must never insert additional extra arguments, or attempt to use any argument other than "host=", as any daemon will get stuck parsing the request line and will never complete the request. Since the client can't tell if the daemon is patched or not, it is not possible to know if additional extra args might actually be able to be safely requested. If we ever need to extend the git daemon protocol to support a new feature, we may have to do something like this to the exchange: # If both support git:// v2 # C: 000cgit://v2 S: 0010ok host user C: 0018host C: 0027git-upload-pack /pub/linux-2.6.git S: ...git-upload-pack header... # If client supports git:// v2, server does not: # C: 000cgit://v2 S: <EOF> C: 003bgit-upload-pack /pub/linux-2.6.git\\0 S: ...git-upload-pack header... This requires the client to create two TCP connections to talk to an older git daemon, however all daemons since the introduction of daemon.c will safely reject the unknown "git://v2" command request, so the client can quite easily determine the server supports an older protocol. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'Documentation/git.txt')
0 files changed, 0 insertions, 0 deletions