"H. Peter Anvin" <hpa@xxxxxxxxx> wrote: > Shawn O. Pearce wrote: >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
