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

Yiyi Sun [off-list ref] 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
000eunpack 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 [off-list ref] wrote:

quoted

On Thu, Jun 17, 2010 at 6:45 AM, Yiyi Sun [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.