{"thread":{"id":"24139","subject":"Fwd: git-receive-pack --stateless-rpc","startedAt":"2010-06-17T13:45:07Z","lastAt":"2010-06-17T15:25:27Z","messageCount":3,"participants":["Yiyi Sun","Shawn Pearce","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143866","messageId":"AANLkTikbUp7_22alAbgNFO30R7vkPUAOr7qvJ6a86Zc7@mail.gmail.com","threadId":"24139","inReplyTo":"AANLkTikwu4iKnG-DzclRPFNF7djNKZ31xR82aO0ryVJ3@mail.gmail.com","subject":"Fwd: git-receive-pack --stateless-rpc","fromName":"Yiyi Sun","fromEmail":"yiyisun@gmail.com","sentAt":"2010-06-17T13:45:07Z","receivedAt":"2010-06-17T13:45:07Z","isPatch":false,"sender":{"key":"yiyisun@gmail.com","avatar":null},"body":"Hi,\n\nI am creating a Git smart HTTP protocol wrapper and run into two\nproblem. I tried the msysGit mailing list and was told to ask them to\nthe main git mailing list.\n\nHere is the story. During 'git push',  I successfully processed the\ninitial GET request of '/info/refs?service=git-receive-pack' by\nsending back the output of 'git receive-pack --stateless-rpc\n--advertise-refs'. Then msysGit did a the POST request. I\ninvoked 'git receive-pack --stateless-rpc', which returned:\n\n0030 000eunpack ok\n0019ok refs/heads/master\n00000000\n\nQuestion #1, Is the result supposed to be something below instead?\n\n000eunpack ok\n0019ok refs/heads/master\n0000\n\nQuestion #2, msysGit cannot parse the result, it displays error message:\n\nfatal: protocol error: bad line length character:\n003\nfatal: The remote end hung up unexpectedly\n\nIt seems that msysGit can read the http response of HTTP GET, but not\nof HTTP POST.\n\n\nCan you please help ?\n\nThanks,\n\nyysun\n"},{"id":"143868","messageId":"AANLkTimZxcljR4soYWVeExr27Md7jmsE1Mfx3Vcbf9SI@mail.gmail.com","threadId":"24139","inReplyTo":"AANLkTikbUp7_22alAbgNFO30R7vkPUAOr7qvJ6a86Zc7@mail.gmail.com","subject":"Re: git-receive-pack --stateless-rpc","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-06-17T14:00:48Z","receivedAt":"2010-06-17T14:00:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Thu, Jun 17, 2010 at 6:45 AM, Yiyi Sun <yiyisun@gmail.com> wrote:\n> I am creating a Git smart HTTP protocol wrapper and run into two\n> problem. I tried the msysGit mailing list and was told to ask them to\n> the main git mailing list.\n>\n> Here is the story. During 'git push',  I successfully processed the\n> initial GET request of '/info/refs?service=git-receive-pack' by\n> sending back the output of 'git receive-pack --stateless-rpc\n> --advertise-refs'. Then msysGit did a the POST request. I\n> invoked 'git receive-pack --stateless-rpc', which returned:\n>\n> 0030 000eunpack ok\n> 0019ok refs/heads/master\n> 00000000\n\nThat doesn't look right to me.  There appears to be a space at the\nstart of the packet (between 0030 and 000e), which would confuse the\nprotocol.  Otherwise, that appears to be a valid response from\nreceive-pack assuming the client asked for side-band-64k in the\nrequest, and it pushed only refs/heads/master.\n\n> Question #1, Is the result supposed to be something below instead?\n>\n> 000eunpack ok\n> 0019ok refs/heads/master\n> 0000\n\nDepends on whether or not the client asked for side-band-64k.  If it\ndid, we wrap it up in a another pkt-line framing like above, and end\nwith another flush-pkt.  If the client didn't ask for side-band-64k,\nthen the above would be the correct response.\n\n> Question #2, msysGit cannot parse the result, it displays error message:\n>\n> fatal: protocol error: bad line length character:\n> 003\n> fatal: The remote end hung up unexpectedly\n\nThis is weird.  \"003\" isn't valid, its not 4 bytes long.  What was\nthat trailing final 4th byte right there?  If its a space like it is\nabove (though then its really in the wrong spot, isn't it?) that would\nthrow it all off.\n\nIt sounds to me like your wrapper is mangling the data that is passing\nthrough it on the way back to the client.\n\n-- \nShawn.\n"},{"id":"143873","messageId":"20100617152527.GA14847@spearce.org","threadId":"24139","inReplyTo":"AANLkTinJadUb48CBKMy1cMlXb2yUvm9uY0nUAQuslrfo@mail.gmail.com","subject":"Re: git-receive-pack --stateless-rpc","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-06-17T15:25:27Z","receivedAt":"2010-06-17T15:25:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Yiyi Sun <yiyisun@gmail.com> wrote:\n> Thanks Shawn for you quick reply. Now I have the answer to question #1.\n> \n> You are so good that spotted the space between 0030 and 000e. It is a\n> byte of value 0x1. I can reproduce the issue using the attached file\n> w/o goimg through my program:\n> \n> --save the file (named input) to and goto the directory\n> git init --bare test\n> cd test\n> cat ../input | git receive-pack .\n> \n> It returns message below, where you can see a funny char there.\n> \n> 00700000000000000000000000000000000000000000 capabilities^{}  report-status dele\n> te-refs side-band-64k ofs-delta\n> Unpacking objects: 100% (6/6), done.\n> 0030☺000eunpack ok\n> 0019ok refs/heads/master\n> 00000000\n> \n> \n> For the \"003\" error. I tired to grab the HTTP output w/o using msysGit. It is\n> \n> HTTP/1.1 200 OK\n> Server: ASP.NET Development Server/10.0.0.0\n> Date: Thu, 17 Jun 2010 13:18:44 GMT\n> X-AspNet-Version: 4.0.30319\n> Cache-Control: private\n> Content-Type: application/x-git-receive-pack-result\n> Content-Length: 52\n> Connection: Close\n> \n> 0030\u0001000eunpack ok\n> 0019ok refs/heads/master\n> 00000000\n> \n> It looks normal. Besides msysGit can candle the output of 'git\n> receive-pack --stateless-rpc\n> --advertise-refs' via HTTP GET the same way my program returns the result.\n> \n> Regards,\n> \n> yysun\n> \n> On Thu, Jun 17, 2010 at 10:00 AM, Shawn Pearce <spearce@spearce.org> wrote:\n> >\n> > On Thu, Jun 17, 2010 at 6:45 AM, Yiyi Sun <yiyisun@gmail.com> wrote:\n> > > I am creating a Git smart HTTP protocol wrapper and run into two\n> > > problem. I tried the msysGit mailing list and was told to ask them to\n> > > the main git mailing list.\n> > >\n> > > Here is the story. During 'git push',  I successfully processed the\n> > > initial GET request of '/info/refs?service=git-receive-pack' by\n> > > sending back the output of 'git receive-pack --stateless-rpc\n> > > --advertise-refs'. Then msysGit did a the POST request. I\n> > > invoked 'git receive-pack --stateless-rpc', which returned:\n> > >\n> > > 0030 000eunpack ok\n> > > 0019ok refs/heads/master\n> > > 00000000\n> >\n> > That doesn't look right to me.  There appears to be a space at the\n> > start of the packet (between 0030 and 000e), which would confuse the\n> > protocol.  Otherwise, that appears to be a valid response from\n> > receive-pack assuming the client asked for side-band-64k in the\n> > request, and it pushed only refs/heads/master.\n> >\n> > > Question #1, Is the result supposed to be something below instead?\n> > >\n> > > 000eunpack ok\n> > > 0019ok refs/heads/master\n> > > 0000\n> >\n> > Depends on whether or not the client asked for side-band-64k.  If it\n> > did, we wrap it up in a another pkt-line framing like above, and end\n> > with another flush-pkt.  If the client didn't ask for side-band-64k,\n> > then the above would be the correct response.\n> >\n> > > Question #2, msysGit cannot parse the result, it displays error message:\n> > >\n> > > fatal: protocol error: bad line length character:\n> > > 003\n> > > fatal: The remote end hung up unexpectedly\n> >\n> > This is weird.  \"003\" isn't valid, its not 4 bytes long.  What was\n> > that trailing final 4th byte right there?  If its a space like it is\n> > above (though then its really in the wrong spot, isn't it?) that would\n> > throw it all off.\n> >\n> > It sounds to me like your wrapper is mangling the data that is passing\n> > through it on the way back to the client.\n\nOh, yea.  That byte 0x01 is the sideband stream number.  I forgot\nabout that needing to be there. :-)\n\nI think your wrapper program is dropping the data there or isn't\nbeing 8 bit clean and is mangling the value.  That's part of\nthe stream.\n\n-- \nShawn.\n"}]}