Re: Git-aware HTTP transport

"H. Peter Anvin" [off-list ref] wrote:

Shawn O. Pearce wrote:

quoted

So this is what may be the final draft of the HTTP protocol.

It looks good to me.  I *really* like the option of combining a redirect  
with a refs list in one reply; this will make things substantially  
easier do deploy on kernel.org, and saves a round trip to boot.

Yea, I had a draft that didn't combine these and I realized how
stupid that was.  So I allowed them to appear together if the
server operator wants to do that.

Just an implementation detail for the server, however: for an *empty*  
repository (one which has no refs at all), the server needs to *not*  
transmit the redirect, or there will be a loop :)  It is unnecessary,  
anyway, since there is inherently nothing to do.

Actually that's not true.  A correct client won't loop.

An empty repository is required to send "refs" section header.
So the client will see the "refs" header and know that the complete
set of refs is following.  Only nothing follows, so it knows the
complete set is the empty set.

A redirect with no ref data won't have the "refs" section header.
So the client knows that it cannot conclude anything from that
exchange and must follow the redirect.

An empty repository sending a redirect will send both "redirect"
and "refs", but no refs follow the "refs" section header.  So the
client knows that it is empty and it does not need to follow the
redirect it received.

Now if the server is stupid and keeps sending a redirect with no
refs header, yea, the client can loop.  So the clients should have
a maximum recursion limit configured into them, just like a good
browser would, so you can't get stuck in an A->B->C->A loop.

-- 
Shawn.