Re: [WIP PATCH 00/14] Protocol v2 patches

[Duy Nguyen <pclouds@gmail.com>]

On Wed, May 25, 2016 at 5:46 AM, David Turner <dturner@twopensource.com> 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