{"thread":{"id":"39832","subject":"Git Smart HTTP with HTTP/2.0","startedAt":"2015-07-11T03:10:48Z","lastAt":"2015-07-11T23:10:06Z","messageCount":5,"participants":["ForceCharlie","Ilari Liusvaara","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"266008","messageId":"BLU403-EAS33258611CF3B5B553B1C996A09E0@phx.gbl","threadId":"39832","inReplyTo":null,"subject":"Git Smart HTTP with HTTP/2.0","fromName":"ForceCharlie","fromEmail":"fbcharlie@outlook.com","sentAt":"2015-07-11T03:10:48Z","receivedAt":"2015-07-11T03:10:48Z","isPatch":false,"sender":{"key":"fbcharlie@outlook.com","avatar":null},"body":"As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently\nimplemented using HTTP/1.1.\n\nFrequently used Git developers often feel Git HTTP protocol is not\nsatisfactory, slow and unstable.This is because the HTTP protocol itself\ndecides\nWhen HTTP/2.0 is published. We might be able to git developers jointly,\nbased on HTTP/2.0 Git-Smart-HTTP service and client support.\nHTTP/2.0: https://tools.ietf.org/html/rfc7540\nGithub Mirror: https://httpwg.github.io/specs/rfc7540.html\nHTTP/2.0 has Flow Controller like SSH, \nHTTP/2.0 has Server Push POST upload-pack can download large more\nobject-pack\n\n......\nlibcurl now has begun to support HTTP/2.0, git is also using curl, as well\nlibgit2 may use libcurl\nI suggest the git of developer joint developer of libgit2 and jgit\ndevelopers discussion based on HTTP/2.0 Git-Smart-HTTP\nNow Subversion developer begin write a New HTTP Protocol for svn (\"HTTP\nv2\"):http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/\nhttp-protocol-v2.txt\nWhat about git ?\n"},{"id":"266020","messageId":"20150711070055.GA4061@LK-Perkele-VII","threadId":"39832","inReplyTo":"BLU403-EAS33258611CF3B5B553B1C996A09E0@phx.gbl","subject":"Re: Git Smart HTTP with HTTP/2.0","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2015-07-11T07:00:55Z","receivedAt":"2015-07-11T07:00:55Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Sat, Jul 11, 2015 at 11:10:48AM +0800, ForceCharlie wrote:\n> As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently\n> implemented using HTTP/1.1.\n\nNit: It is HTTP/2.\n \n> Frequently used Git developers often feel Git HTTP protocol is not\n> satisfactory, slow and unstable.This is because the HTTP protocol itself\n> decides\n\nNote that there are already two versions of HTTP transport, the old \"dumb\"\none and the newer \"smart\" one.\n\nThe smart one is difficult to speed up (due to nature of the negotiations),\nbut usually is pretty reliable (the efficiency isn't horrible).\n\nNow, the old \"dumb\" protocol is pretty unreliable and slow. HTTP/2 probably\ncan't do anything with the reliability problems, but probably could improve\nthe speed a bit.\n\nWebsockets over HTTP/2 (a.k.a. \"websockets2\") has not been defined yet.\nWith Websockets(1), it would probably already be possible to tunnel the\nnative git smart transport protocol over it. Probably not worth it.\n\n> When HTTP/2.0 is published. We might be able to git developers jointly,\n> based on HTTP/2.0 Git-Smart-HTTP service and client support.\n> HTTP/2.0: https://tools.ietf.org/html/rfc7540\n\nWell, it is published already.\n \n\n-Ilari\n"},{"id":"266042","messageId":"CAJo=hJs21m1C6+rdvCid311-TapK=QKLkqrH8aUZmzHH7CpVug@mail.gmail.com","threadId":"39832","inReplyTo":"20150711070055.GA4061@LK-Perkele-VII","subject":"Re: Git Smart HTTP with HTTP/2.0","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2015-07-11T17:23:09Z","receivedAt":"2015-07-11T17:23:09Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sat, Jul 11, 2015 at 12:00 AM, Ilari Liusvaara\n<ilari.liusvaara@elisanet.fi> wrote:\n> On Sat, Jul 11, 2015 at 11:10:48AM +0800, ForceCharlie wrote:\n>> As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently\n>> implemented using HTTP/1.1.\n>\n> Nit: It is HTTP/2.\n>\n>> Frequently used Git developers often feel Git HTTP protocol is not\n>> satisfactory, slow and unstable.This is because the HTTP protocol itself\n>> decides\n>\n> Note that there are already two versions of HTTP transport, the old \"dumb\"\n> one and the newer \"smart\" one.\n>\n> The smart one is difficult to speed up (due to nature of the negotiations),\n> but usually is pretty reliable (the efficiency isn't horrible).\n\nThe negotiation in smart-HTTP actually has some bad corner cases. Each\nround of negotiation requires a new POST resupplying all previously\nagreed upon SHA-1s, and a batch of new SHA-1s. We have observed many\nrounds where this POST is MiBs in size because the peers can't quite\nagree and have to keep digging through history.\n\nThe native protocol on git:// and SSH is not as bad. Negotiation is\nstill many rounds, but these are pipelined and each round does not\nneed to repeat the prior round, as the server has a single stream and\nis saving state.\n\n> Now, the old \"dumb\" protocol is pretty unreliable and slow. HTTP/2 probably\n> can't do anything with the reliability problems, but probably could improve\n> the speed a bit.\n>\n> Websockets over HTTP/2 (a.k.a. \"websockets2\") has not been defined yet.\n> With Websockets(1), it would probably already be possible to tunnel the\n> native git smart transport protocol over it. Probably not worth it.\n\nAnother option is to tunnel using gRPC (grpc.io). libcurl probably\ncan't do this. And linking grpc.io library into git-core is crazy. So\nits probably a non-starter. But food for thought.\n\nBut, at $DAY_JOB we tunnel the native bidirectional protocol in\ngrpc.io's predecessor, and it works quite well for us.\n"},{"id":"266043","messageId":"20150711182657.GA8589@LK-Perkele-VII","threadId":"39832","inReplyTo":"CAJo=hJs21m1C6+rdvCid311-TapK=QKLkqrH8aUZmzHH7CpVug@mail.gmail.com","subject":"Re: Git Smart HTTP with HTTP/2.0","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2015-07-11T18:26:57Z","receivedAt":"2015-07-11T18:26:57Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Sat, Jul 11, 2015 at 10:23:09AM -0700, Shawn Pearce wrote:\n> On Sat, Jul 11, 2015 at 12:00 AM, Ilari Liusvaara\n> <ilari.liusvaara@elisanet.fi> wrote:\n> > On Sat, Jul 11, 2015 at 11:10:48AM +0800, ForceCharlie wrote:\n> >\n> >> Frequently used Git developers often feel Git HTTP protocol is not\n> >> satisfactory, slow and unstable.This is because the HTTP protocol itself\n> >> decides\n> >\n> > Note that there are already two versions of HTTP transport, the old \"dumb\"\n> > one and the newer \"smart\" one.\n> >\n> > The smart one is difficult to speed up (due to nature of the negotiations),\n> > but usually is pretty reliable (the efficiency isn't horrible).\n> \n> The negotiation in smart-HTTP actually has some bad corner cases. Each\n> round of negotiation requires a new POST resupplying all previously\n> agreed upon SHA-1s, and a batch of new SHA-1s. We have observed many\n> rounds where this POST is MiBs in size because the peers can't quite\n> agree and have to keep digging through history.\n\nOh yeah that... Well, that is artifact of HTTP semantics.\n\n> > Now, the old \"dumb\" protocol is pretty unreliable and slow. HTTP/2 probably\n> > can't do anything with the reliability problems, but probably could improve\n> > the speed a bit.\n> >\n> > Websockets over HTTP/2 (a.k.a. \"websockets2\") has not been defined yet.\n> > With Websockets(1), it would probably already be possible to tunnel the\n> > native git smart transport protocol over it. Probably not worth it.\n> \n> Another option is to tunnel using gRPC (grpc.io). libcurl probably\n> can't do this. And linking grpc.io library into git-core is crazy. So\n> its probably a non-starter. But food for thought.\n\nWouldn't it link into git-remote-http (and on the server side, one\ncould use pipes to talk to git)?\n\nBut supporting websockets in git-remote-http could get annoying,\nespecially for wss:// (https://). Dunno how bad gRPC would be.\n\n\n\n-Ilari\n"},{"id":"266045","messageId":"CAJo=hJuM70o8+U3Wt3rRzyrB1O=Q+wz3bGZVFa07zRQ0Ughk9g@mail.gmail.com","threadId":"39832","inReplyTo":"20150711182657.GA8589@LK-Perkele-VII","subject":"Re: Git Smart HTTP with HTTP/2.0","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2015-07-11T23:10:06Z","receivedAt":"2015-07-11T23:10:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sat, Jul 11, 2015 at 11:26 AM, Ilari Liusvaara\n<ilari.liusvaara@elisanet.fi> wrote:\n> On Sat, Jul 11, 2015 at 10:23:09AM -0700, Shawn Pearce wrote:\n>>\n>> > Websockets over HTTP/2 (a.k.a. \"websockets2\") has not been defined yet.\n>> > With Websockets(1), it would probably already be possible to tunnel the\n>> > native git smart transport protocol over it. Probably not worth it.\n>>\n>> Another option is to tunnel using gRPC (grpc.io). libcurl probably\n>> can't do this. And linking grpc.io library into git-core is crazy. So\n>> its probably a non-starter. But food for thought.\n>\n> Wouldn't it link into git-remote-http (and on the server side, one\n> could use pipes to talk to git)?\n>\n> But supporting websockets in git-remote-http could get annoying,\n> especially for wss:// (https://). Dunno how bad gRPC would be.\n\nWe wrote it as git-remote-$THING, invoked with $THING:// URLs. And\ngit-remote-$THING just implements the \"connect\" helper protocol. Its\nmuch simpiler than git-remote-http.\n\nMaybe its done that way in git-core as http2:// aka git-remote-http2.\n\nOr the git-remote-http helper connects to the remote system and tries\nto guess if it supports Git on HTTP/2 before responding to the\ncapabilities request from transport code. If yes, it replies with\nconnect, if no, it does the current fetch and push protocol.\n"}]}