"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> wrote: >> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. -- 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
