On Wed, May 25, 2016 at 5:46 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > 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? It simply takes one more round-trip to negotiate. Not the best thing, but... > 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. Yeah. And libcurl probably will not support websockets even in long run. I've been searching for a websocket implementation for git and finally settled for netcat-like programs, sitting in front of git and dealing with network just like ssh. It will be the simplest way to add either websocket or http/2 support. If either protocol gets popular enough, smart-http can become a fall-back mechanism where performance does not matter much. -- Duy -- 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