Re: Git-aware HTTP transport

[Junio C Hamano <gitster@pobox.com>]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> 
>> > HTTP Redirects
>> > --------------
>> >
>> > If a POST request results in an HTTP 302 or 303 redirect response
>> > clients should retry the request by updating the URL and POSTing
>> > the same request to the new location.  Subsequent requests should
>> > still be sent to the original URL.
>> 
>> At the first reading I was confused because this seemed to contradict with
>> the server pinning that is done by the payload level redirect.
>
> This is meant to help load balancing initially target to a server.
> I think its also reasonable to honor a transport level redirect,
> much as we honor whatever route IP gives us (not that we have a
> lot of choice - or even want one at that level).

Yeah, I think understood what you are trying to achieve here after reading
the document twice.

I was just pointing out that the language (or presentation order) was
confusing to me and I needed to read these two sections twice to see the
difference between the two redirects.

>> Is there a way to detect bad clients that does not obey this rule without
>> server side states?
>
> No.  Is that really a concern though?

I was more concerned about a bad/broken client not giving up forever, and
not giving the server enough cue to give up, saying "I've conversed with
this guy long enough but haven't reached the conclusion yet --- there is
something wrong".  Even without server side states, if we were to trust
clients, we can add "this is Nth round" to the protocol to help the server
detect "long enough" part, but that somehow does not feel right.