Thread (34 messages) flat view 34 messages, 4 authors, 2016-06-16

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

From: Duy Nguyen <hidden>
Date: 2016-06-16 02:19:35

On Wed, May 25, 2016 at 5:46 AM, David Turner [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help