I was looking at this again today, and noticed that it doesn't really address the HTTP case. The central problem is that protocol v2 goes like this: server: I have capabilities w,x,y, and z client: I want capabilities x and z. But HTTP goes like this: client: [request] server: [response] I tried to make libcurl do the receive-before-sending thing, but it doesn't seem to be designed for it (even if you prime things by sending a "hello" from the client first). My thought was to hook up CURLOPT_READFUNCTION and CURLOPT_WRITEFUNCTION, and have the read function return CURL_READFUNC_PAUSE and then have the write (=client receiving data ) function unpause the reader (= client sending data) once it gets the capabilities. But apparently pausing only works with chunked encoding, which seems to cause Apache's mod_cgi to fail. Maybe I'm missing something. Has anyone else ever made something like this work? Of course, I could always use CURLOPT_CONNECT_ONLY to write my own HTTP client, but that seems pretty unreasonable. I also looked to see if libcurl had websockets support, since that's one kind of bidirectional conversation over HTTP, but it doesn't seem to. Another choice is to make a separate /capabilities endpoint that gets hit before /info/refs. This is a bit bad because: (a) it's another HTTP request (b) it adds implicit state to the HTTP conversation. If multiple git servers were behind a load balancer, you might end up getting server A for /capabilities and server B for /info/refs, and those servers might have different capabilities. This is not impossible when testing a git server upgrade on one machine before rolling it out to a whole fleet. Maybe the rule for clients re capabilities is that they can request whatever capabilities they want, but the server is free to ignore that request and send whatever data it feels like. That's not great, but it should work (I think). Does anyone else have any thoughts on how this ought to work? -- 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