On 06/05/2012 08:54 PM, Shawn Pearce wrote:
On Tue, Jun 5, 2012 at 11:41 AM, Stephan Peijnik<stephan@xxxxxxxxxx> wrote:
To be honest, I didn't know smart-http support yet. Is that the approach
introduced with git 1.6.6?
Yes. So its been around for a while now. Like 2 years.
I have just read-up on that. My fault.
If so, that approach uses multiple POST requests, meaning multiple TCP and
HTTP connections need to be established, multiple requests processed, etc.
Its actually only one TCP connection... assuming the servers in
between the client and the Git endpoint correctly support HTTP
keep-alive semantics.
With keep-alive that is true, but a quick check on the actual data
exchange tells me that multiple HTTP requests are still needed. But I
guess the overhead caused by a second HTTP requests can be ignored.
How does this fair going through crappy proxy servers that perform
man-in-the-middle attacks on SSL connections? Just last week I was
trying to help someone whose local proxy server was MITM the SSL
session behind Git's back, and their IT department forgot to install
the proxy server's certificate into the system certificate directory.
They only installed it into the browser. That proxy also doesn't
correctly grok HTTP 1.1 keep-alive with chunked transfer encodings.
Let alone something as new as web sockets.
Proxy servers could be an issue, yes. For proxy servers not acting as
MITM and which are supporting CONNECT this shouldn't be an issue though.
Also, given the current HTML5 hype things should get better in the
future, but you are correct about potential current issues with the
approach.
So in comparison there is possibly a lot less overhead and, in theory, the
performance should be comparable to running the smart protocol over ssh.
Personally I'd say the WebSocket approach is cleaner than the HTTP-POST
approach.
This may be true. But its also a lot more complex to implement. I
noticed you reused Python code to help make this work.
The only reason I used Python is that I wanted to quickly come up with a
prototype. I am also aware of the fact that a proper implementation
should possibly be done in C.
Let me know when there is a GPLv2 client library that implements sufficient
semantics for WebSockets that Git can bundle it out of the box.
As for the WebSocket client library that is GPLv2 compatible: there is
at least libwebsockets [0], which is licensed under the terms of the
LGPL v2.1, and as such GPLv2 only compatible.
What do you think about using this as basis for a proper implementation?
And let me know when most corporate IT proxy servers correctly grok
WebSockets. I suspect it will be many more years given that they still
can't even grok chunked transfer encoding.
As stated above, this could be a problem, yes.
The question is whether one only wants to provide an alternative
approach when it is usable for everyone.
My intention never was to have the current http implementation, be it
the dumb or http-backend one, replaced. The idea here was to provide an
additional option that makes use of a fairly new technology, with all
benefits and drawbacks of using something new.
Thanks for your feedback.
-- Stephan
[0] http://git.warmcat.com/cgi-bin/cgit/libwebsockets/
--
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