Shawn O. Pearce wrote:
Chunked Transfer Encoding ------------------------- For performance reasons the HTTP/1.1 chunked transfer encoding is used frequently to transfer variable length objects. This avoids needing to produce large results in memory to compute the proper content-length.
One more thing about chunked transfer encodings: you cannot assume that a proxy will maintain chunk boundaries, any more than you can assume that a firewall will maintain TCP packet boundaries.
Detecting Smart Servers ----------------------- HTTP clients can detect a smart Git-aware server by sending the show-ref request (below) to the server. If the response has a status of 200 and the magic x-application/git-refs content type then the server can be assumed to be a smart Git-aware server. If any other response is received the client must assume dumb protocol support, as the server did not correctly response to the request.
I think it should be application/x-git-refs, but that's splitting hairs.
Obtains the available refs from the remote repository. The response is a sequence of git "packet lines", one per ref, and a final flush packet line to indicate the end of stream. C: GET /path/to/repository.git?show-ref HTTP/1.0
I really think it would make more sense to use POST requests for everything, and have the command part of the POSTed payload. Putting stuff in the URL just complicates the namespace to the detriment of the admin.
S: HTTP/1.1 200 OK S: Content-Type: x-application/git-refs S: Transfer-Encoding: chunked
Transfer-encoding: chunked is illegal with a HTTP/1.0 client. -hpa -- 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
