{"thread":{"id":"30721","subject":"git smart protocol via WebSockets - feedback wanted","startedAt":"2012-06-05T18:20:49Z","lastAt":"2012-06-05T21:11:29Z","messageCount":7,"participants":["Stephan Peijnik","Junio C Hamano","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"192937","messageId":"jqlim2$6vt$1@dough.gmane.org","threadId":"30721","inReplyTo":null,"subject":"git smart protocol via WebSockets - feedback wanted","fromName":"Stephan Peijnik","fromEmail":"stephan@peijnik.at","sentAt":"2012-06-05T18:20:49Z","receivedAt":"2012-06-05T18:20:49Z","isPatch":false,"sender":{"key":"stephan@peijnik.at","avatar":null},"body":"Dear list,\n\nSince I have been working on a proof of concept showing that git's smart \nprotocol can be tunneled via WebSocket connections quite easily [0] I \nwanted to ask for some feedback on the idea in general and on my \nimplementation [1].\n\nSo, basically, what do you think about tunneling git's smart protocol \nvia WebSockets (and thus HTTP)?\nDo you believe that a full implementation of this, as opposed to the \ncurrent proof of concept, is worthwhile?\nAre there any issues with this approach I missed (apart from the missing \nauthentication/authorization in the server component of course)?\n\nThanks in advance for your input.\n\nRegards,\n\nStephan\n\n[0] \nhttp://blog.sp.or.at/2012/06/git-smart-protocol-via-websockets-proof.html\n[1] https://github.com/speijnik/gitws\n"},{"id":"192938","messageId":"7vpq9dobjo.fsf@alter.siamese.dyndns.org","threadId":"30721","inReplyTo":"jqlim2$6vt$1@dough.gmane.org","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-05T18:31:39Z","receivedAt":"2012-06-05T18:31:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"How does this compare with the smart-http support that tunnels the\ngit protocol over http (with some butchering)?\n"},{"id":"192940","messageId":"CAJo=hJtUbuWrVjVMAZirgD2O3f4TXa8YSYURSLUB5t3AD8Czig@mail.gmail.com","threadId":"30721","inReplyTo":"jqlim2$6vt$1@dough.gmane.org","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-06-05T18:36:28Z","receivedAt":"2012-06-05T18:36:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Jun 5, 2012 at 11:20 AM, Stephan Peijnik <stephan@peijnik.at> wrote:\n> Since I have been working on a proof of concept showing that git's smart\n> protocol can be tunneled via WebSocket connections quite easily [0] I wanted\n> to ask for some feedback on the idea in general and on my implementation\n> [1].\n>\n> So, basically, what do you think about tunneling git's smart protocol via\n> WebSockets (and thus HTTP)?\n...\n> [0]\n> http://blog.sp.or.at/2012/06/git-smart-protocol-via-websockets-proof.html\n> [1] https://github.com/speijnik/gitws\n\nHow does this compare with the smart HTTP protocol that has been\nsupported since Git 1.6.6, and uses the git-http-backend CGI at the\nserver side?\n"},{"id":"192941","messageId":"jqljtk$h6d$1@dough.gmane.org","threadId":"30721","inReplyTo":"7vpq9dobjo.fsf@alter.siamese.dyndns.org","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Stephan Peijnik","fromEmail":"stephan@peijnik.at","sentAt":"2012-06-05T18:41:56Z","receivedAt":"2012-06-05T18:41:56Z","isPatch":false,"sender":{"key":"stephan@peijnik.at","avatar":null},"body":"On 06/05/2012 08:31 PM, Junio C Hamano wrote:\n> How does this compare with the smart-http support that tunnels the\n> git protocol over http (with some butchering)?\n\nTo be honest, I didn't know smart-http support yet. Is that the approach \nintroduced with git 1.6.6?\n\nIf so, that approach uses multiple POST requests, meaning multiple TCP \nand HTTP connections need to be established, multiple requests \nprocessed, etc.\n\nThe WebSocket approach uses a single HTTP connection which gets upgraded \nto a WebSocket. This WebSocket then allows the same communication to \nhappen as with the ssh implementation.\n\nSo in comparison there is possibly a lot less overhead and, in theory, \nthe performance should be comparable to running the smart protocol over \nssh. Personally I'd say the WebSocket approach is cleaner than the \nHTTP-POST approach.\n\n-- Stephan\n"},{"id":"192942","messageId":"CAJo=hJue20kwo-jo8x8dC7AUVs3oP=ZC9aCq_ncq3+MWr9VmgQ@mail.gmail.com","threadId":"30721","inReplyTo":"jqljtk$h6d$1@dough.gmane.org","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-06-05T18:54:48Z","receivedAt":"2012-06-05T18:54:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Jun 5, 2012 at 11:41 AM, Stephan Peijnik <stephan@peijnik.at> wrote:\n> On 06/05/2012 08:31 PM, Junio C Hamano wrote:\n>>\n>> How does this compare with the smart-http support that tunnels the\n>> git protocol over http (with some butchering)?\n>\n>\n> To be honest, I didn't know smart-http support yet. Is that the approach\n> introduced with git 1.6.6?\n\nYes. So its been around for a while now. Like 2 years.\n\n> If so, that approach uses multiple POST requests, meaning multiple TCP and\n> HTTP connections need to be established, multiple requests processed, etc.\n\nIts actually only one TCP connection... assuming the servers in\nbetween the client and the Git endpoint correctly support HTTP\nkeep-alive semantics.\n\n> The WebSocket approach uses a single HTTP connection which gets upgraded to\n> a WebSocket. This WebSocket then allows the same communication to happen as\n> with the ssh implementation.\n\nHow does this fair going through crappy proxy servers that perform\nman-in-the-middle attacks on SSL connections? Just last week I was\ntrying to help someone whose local proxy server was MITM the SSL\nsession behind Git's back, and their IT department forgot to install\nthe proxy server's certificate into the system certificate directory.\nThey only installed it into the browser. That proxy also doesn't\ncorrectly grok HTTP 1.1 keep-alive with chunked transfer encodings.\nLet alone something as new as web sockets.\n\n> So in comparison there is possibly a lot less overhead and, in theory, the\n> performance should be comparable to running the smart protocol over ssh.\n> Personally I'd say the WebSocket approach is cleaner than the HTTP-POST\n> approach.\n\nThis may be true. But its also a lot more complex to implement. I\nnoticed you reused Python code to help make this work. Let me know\nwhen there is a GPLv2 client library that implements sufficient\nsemantics for WebSockets that Git can bundle it out of the box. And\nlet me know when most corporate IT proxy servers correctly grok\nWebSockets. I suspect it will be many more years given that they still\ncan't even grok chunked transfer encoding.\n"},{"id":"192944","messageId":"jqlml0$83h$1@dough.gmane.org","threadId":"30721","inReplyTo":"CAJo=hJue20kwo-jo8x8dC7AUVs3oP=ZC9aCq_ncq3+MWr9VmgQ@mail.gmail.com","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Stephan Peijnik","fromEmail":"stephan@peijnik.at","sentAt":"2012-06-05T19:28:31Z","receivedAt":"2012-06-05T19:28:31Z","isPatch":false,"sender":{"key":"stephan@peijnik.at","avatar":null},"body":"On 06/05/2012 08:54 PM, Shawn Pearce wrote:\n> On Tue, Jun 5, 2012 at 11:41 AM, Stephan Peijnik<stephan@peijnik.at>  wrote:\n>> To be honest, I didn't know smart-http support yet. Is that the approach\n>> introduced with git 1.6.6?\n>\n> Yes. So its been around for a while now. Like 2 years.\n\nI have just read-up on that. My fault.\n\n>> If so, that approach uses multiple POST requests, meaning multiple TCP and\n>> HTTP connections need to be established, multiple requests processed, etc.\n>\n> Its actually only one TCP connection... assuming the servers in\n> between the client and the Git endpoint correctly support HTTP\n> keep-alive semantics.\n\nWith keep-alive that is true, but a quick check on the actual data \nexchange tells me that multiple HTTP requests are still needed. But I \nguess the overhead caused by a second HTTP requests can be ignored.\n\n> How does this fair going through crappy proxy servers that perform\n> man-in-the-middle attacks on SSL connections? Just last week I was\n> trying to help someone whose local proxy server was MITM the SSL\n> session behind Git's back, and their IT department forgot to install\n> the proxy server's certificate into the system certificate directory.\n> They only installed it into the browser. That proxy also doesn't\n> correctly grok HTTP 1.1 keep-alive with chunked transfer encodings.\n> Let alone something as new as web sockets.\n\nProxy servers could be an issue, yes. For proxy servers not acting as \nMITM and which are supporting CONNECT this shouldn't be an issue though.\nAlso, given the current HTML5 hype things should get better in the \nfuture, but you are correct about potential current issues with the \napproach.\n\n>> So in comparison there is possibly a lot less overhead and, in theory, the\n>> performance should be comparable to running the smart protocol over ssh.\n>> Personally I'd say the WebSocket approach is cleaner than the HTTP-POST\n>> approach.\n>\n> This may be true. But its also a lot more complex to implement. I\n> noticed you reused Python code to help make this work.\n\nThe only reason I used Python is that I wanted to quickly come up with a \nprototype. I am also aware of the fact that a proper implementation \nshould possibly be done in C.\n\n> Let me know when there is a GPLv2 client library that implements sufficient\n> semantics for WebSockets that Git can bundle it out of the box.\n\nAs for the WebSocket client library that is GPLv2 compatible: there is \nat least libwebsockets [0], which is licensed under the terms of the \nLGPL v2.1, and as such GPLv2 only compatible.\nWhat do you think about using this as basis for a proper implementation?\n\n> And let me know when most corporate IT proxy servers correctly grok\n> WebSockets. I suspect it will be many more years given that they still\n> can't even grok chunked transfer encoding.\n\nAs stated above, this could be a problem, yes.\nThe question is whether one only wants to provide an alternative \napproach when it is usable for everyone.\nMy intention never was to have the current http implementation, be it \nthe dumb or http-backend one, replaced. The idea here was to provide an \nadditional option that makes use of a fairly new technology, with all \nbenefits and drawbacks of using something new.\n\nThanks for your feedback.\n\n-- Stephan\n\n[0] http://git.warmcat.com/cgi-bin/cgit/libwebsockets/\n"},{"id":"192953","messageId":"CAJo=hJtSow1pBQ8d26NBdrmay7aEHP6btdspQ4YsjLtZWQt1TA@mail.gmail.com","threadId":"30721","inReplyTo":"jqlml0$83h$1@dough.gmane.org","subject":"Re: git smart protocol via WebSockets - feedback wanted","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-06-05T21:11:29Z","receivedAt":"2012-06-05T21:11:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Jun 5, 2012 at 12:28 PM, Stephan Peijnik <stephan@peijnik.at> wrote:\n> On 06/05/2012 08:54 PM, Shawn Pearce wrote:\n>>\n>> Its actually only one TCP connection... assuming the servers in\n>> between the client and the Git endpoint correctly support HTTP\n>> keep-alive semantics.\n>\n> With keep-alive that is true, but a quick check on the actual data exchange\n> tells me that multiple HTTP requests are still needed. But I guess the\n> overhead caused by a second HTTP requests can be ignored.\n\nThere is extra overhead from the HTTP request headers, this is true.\nFortunately its relatively small and bounded.\n\nThere isn't that much additional latency in the smart HTTP protocol.\nWhere the client is waiting on data from the server is where we end an\nHTTP request and start a new one. The mulit_ack capability on normal\nTCP or SSH connections does get to interleave a bit more in the native\nprotocol to try and hide the RTT latency. I don't know that anyone has\ndone extensive testing to determine how effective that is vs. the\nbatch sizes we run in the HTTP POST format. With the key part being\nhow quickly the overall negotiation exchange went for the end-user.\n\nColby Ranger's recent contribution to contrib/persistent-https\nprovides a local proxy server for Git over HTTP that tries to reuse\nHTTP connections across Git command invocations. This can go further\nthan even git:// does with TCP connection reuse, cutting latency. Of\ncourse a user can do the same thing with their own local HTTP proxy,\nbut persistent-https can be easier to install and configure.\n\n>> How does this fair going through crappy proxy servers that perform\n>> man-in-the-middle attacks on SSL connections? Just last week I was\n>> trying to help someone whose local proxy server was MITM the SSL\n>> session behind Git's back, and their IT department forgot to install\n>> the proxy server's certificate into the system certificate directory.\n>> They only installed it into the browser. That proxy also doesn't\n>> correctly grok HTTP 1.1 keep-alive with chunked transfer encodings.\n>> Let alone something as new as web sockets.\n>\n> Proxy servers could be an issue, yes. For proxy servers not acting as MITM\n> and which are supporting CONNECT this shouldn't be an issue though.\n\nI am still annoyed by the failure of \"Expect: 100-continue\". The\noriginal smart HTTP protocol used this during push to try and avoid\nsending a 100 MiB POST payload before finding out authentication is\nrequired and failing. It turns out far too many HTTP servers and proxy\nservers do not correctly implement 100-continue to rely on it in the\nprotocol, so we had to back that out and use a special POST body with\n4 bytes to \"probe\" the remote server before sending the full payload.\n\n100-continue is in RFC 2616, dated June 1999. My calendar says June\n2012. So 13 years later and we still cannot rely on 100-continue as\nspecified by RFC 2616 working correctly on the public Internet.\n\nChunked Transfer-Encoding is described in RFC 2038, dated Jan 1997 and\nis the RFC that RFC 2616 made obsolete. This is still not working\nreliable everywhere... 15 years after being specified proxy servers\nare still converting chunked transfer encoding to \"Connection: close\"\nand destroying any HTTP keep-alive that might have been possible.\n\nBasically I learned a lot in the past 2 years deploying Git on a\nrather broad scale with HTTP. The public Internet doesn't resemble the\nstandards enough, and you really have to code to the lowest common\ndenominator, because there is some user out there that matters to you\nwho is stuck behind some HTTP proxy that implements the HTTP standard\nas it existed in 1995 and whose managers/suppliers refuse to bring\nforward to the current century.\n\n> Also, given the current HTML5 hype things should get better in the future,\n> but you are correct about potential current issues with the approach.\n\nWebSockets seems pretty full of fail to me.\n\nThe protocol specification is really complex. Its reimplementing TCP\non top of HTTP to work around an artificial browser imposed limitation\non the number of suggested HTTP connections the browser opens to the\nserver. Meanwhile SPDY goes the other direction and tries to support\nmultiplexing a larger number of HTTP requests into a single TCP\nconnection, while reusing a lot of header data across those requests.\nI have higher hopes for SPDY adoption than for WebSockets. SPDY solves\na lot of common problems on the Internet that social networking sites\ncare about, like time to load assets for a game, or that publishers\ncare about, like time to load all assets for a site on initial visit,\nincreasing the chances the user doesn't immediately jump away due to\nperceived high loading time.\n\nWebSockets is a large amount of wanking to make playing a game written\nin JavaScript easier, using a very ugly protocol, and a much more\ncomplex software stack. I think the WebSockets authors saw the problem\nof HTTP connections in a browser and solved it the wrong way. They saw\nthe bidirectional stream problem... and solved it for a very narrow\nuse case. SPDY also relies on a bidirectional stream, but it lets the\nserver do more, like suggest pushing assets down ahead of the browser\nrealizing it needs them.\n\n>>> So in comparison there is possibly a lot less overhead and, in theory,\n>>> the\n>>> performance should be comparable to running the smart protocol over ssh.\n>>> Personally I'd say the WebSocket approach is cleaner than the HTTP-POST\n>>> approach.\n>>\n>> This may be true. But its also a lot more complex to implement. I\n>> noticed you reused Python code to help make this work.\n>\n> The only reason I used Python is that I wanted to quickly come up with a\n> prototype. I am also aware of the fact that a proper implementation should\n> possibly be done in C.\n\nAny implementation of a new embedding of the Git protocol into e.g.\nWebSockets also requires implementing it in Java for JGit, both client\nand server, and probably also in Python for Dulwich, again client and\nserver. Given that WebSockets is all about cramming TCP into HTTP in\nSSL in TCP, and doesn't always work on the public Internet given the\ncurrent state of proxy servers, I just don't see the value in this.\n\nWe have to provide complete support across the major Git\nimplementations, otherwise users will come to this mailing list and\ncomplain about how implementation $X cannot talk to server running $Y\nbecause server owner $Z only configured the new fangled WebSockets\nprotocol. And I am simply too lazy to write a procmail script to\ndirect all such inquiries to your address.\n\n>> Let me know when there is a GPLv2 client library that implements\n>> sufficient\n>> semantics for WebSockets that Git can bundle it out of the box.\n>\n> As for the WebSocket client library that is GPLv2 compatible: there is at\n> least libwebsockets [0], which is licensed under the terms of the LGPL v2.1,\n> and as such GPLv2 only compatible.\n\nOK, yay. Someone actually bothered to implement this?\n\n>> And let me know when most corporate IT proxy servers correctly grok\n>> WebSockets. I suspect it will be many more years given that they still\n>> can't even grok chunked transfer encoding.\n>\n> As stated above, this could be a problem, yes.\n> The question is whether one only wants to provide an alternative approach\n> when it is usable for everyone.\n\nI predict WebSockets will be usable by everyone about... never. Its\ntoo complex of a standard, and too narrow of a corner case. We are\ntalking about proxy servers that can't do 100-continue correctly,\nbecause async network IO was too hard for them to code. Those authors\nand their software will never support WebSockets' bidirectional\nrequirement. WebSockets isn't critical to browse the web. It never\nwill be. 100-continue might be useful with form based file uploads,\nwhich are at least 100x more common on the web than a WebSocket\npowered thing. Seriously. Call me when WebSockets is actually working.\nI'd like to come back and see what the world looks like in 2152.\n\n> My intention never was to have the current http implementation, be it the\n> dumb or http-backend one, replaced. The idea here was to provide an\n> additional option that makes use of a fairly new technology, with all\n> benefits and drawbacks of using something new.\n\nYou are free to develop your own remote helper that does this. But I\ndon't expect any Git distribution or implementation to be supporting\nit.\n"}]}