Re: git-receive-pack --stateless-rpc

["Shawn O. Pearce" <spearce@spearce.org>]

Yiyi Sun <yiyisun@gmail.com> wrote:
> Thanks Shawn for you quick reply. Now I have the answer to question #1.
> 
> You are so good that spotted the space between 0030 and 000e. It is a
> byte of value 0x1. I can reproduce the issue using the attached file
> w/o goimg through my program:
> 
> --save the file (named input) to and goto the directory
> git init --bare test
> cd test
> cat ../input | git receive-pack .
> 
> It returns message below, where you can see a funny char there.
> 
> 00700000000000000000000000000000000000000000 capabilities^{}  report-status dele
> te-refs side-band-64k ofs-delta
> Unpacking objects: 100% (6/6), done.
> 0030☺000eunpack ok
> 0019ok refs/heads/master
> 00000000
> 
> 
> For the "003" error. I tired to grab the HTTP output w/o using msysGit. It is
> 
> HTTP/1.1 200 OK
> Server: ASP.NET Development Server/10.0.0.0
> Date: Thu, 17 Jun 2010 13:18:44 GMT
> X-AspNet-Version: 4.0.30319
> Cache-Control: private
> Content-Type: application/x-git-receive-pack-result
> Content-Length: 52
> Connection: Close
> 
> 0030\x01000eunpack ok
> 0019ok refs/heads/master
> 00000000
> 
> It looks normal. Besides msysGit can candle the output of 'git
> receive-pack --stateless-rpc
> --advertise-refs' via HTTP GET the same way my program returns the result.
> 
> Regards,
> 
> yysun
> 
> On Thu, Jun 17, 2010 at 10:00 AM, Shawn Pearce <spearce@spearce.org> wrote:
> >
> > On Thu, Jun 17, 2010 at 6:45 AM, Yiyi Sun <yiyisun@gmail.com> wrote:
> > > I am creating a Git smart HTTP protocol wrapper and run into two
> > > problem. I tried the msysGit mailing list and was told to ask them to
> > > the main git mailing list.
> > >
> > > Here is the story. During 'git push',  I successfully processed the
> > > initial GET request of '/info/refs?service=git-receive-pack' by
> > > sending back the output of 'git receive-pack --stateless-rpc
> > > --advertise-refs'. Then msysGit did a the POST request. I
> > > invoked 'git receive-pack --stateless-rpc', which returned:
> > >
> > > 0030 000eunpack ok
> > > 0019ok refs/heads/master
> > > 00000000
> >
> > That doesn't look right to me.  There appears to be a space at the
> > start of the packet (between 0030 and 000e), which would confuse the
> > protocol.  Otherwise, that appears to be a valid response from
> > receive-pack assuming the client asked for side-band-64k in the
> > request, and it pushed only refs/heads/master.
> >
> > > Question #1, Is the result supposed to be something below instead?
> > >
> > > 000eunpack ok
> > > 0019ok refs/heads/master
> > > 0000
> >
> > Depends on whether or not the client asked for side-band-64k.  If it
> > did, we wrap it up in a another pkt-line framing like above, and end
> > with another flush-pkt.  If the client didn't ask for side-band-64k,
> > then the above would be the correct response.
> >
> > > Question #2, msysGit cannot parse the result, it displays error message:
> > >
> > > fatal: protocol error: bad line length character:
> > > 003
> > > fatal: The remote end hung up unexpectedly
> >
> > This is weird.  "003" isn't valid, its not 4 bytes long.  What was
> > that trailing final 4th byte right there?  If its a space like it is
> > above (though then its really in the wrong spot, isn't it?) that would
> > throw it all off.
> >
> > It sounds to me like your wrapper is mangling the data that is passing
> > through it on the way back to the client.

Oh, yea.  That byte 0x01 is the sideband stream number.  I forgot
about that needing to be there. :-)

I think your wrapper program is dropping the data there or isn't
being 8 bit clean and is mangling the value.  That's part of
the stream.

-- 
Shawn.