Hi, On Wed, Dec 2, 2009 at 12:59 AM, Martin Storsjö <martin@xxxxxxxxx> wrote: > On Tue, 1 Dec 2009, Shawn O. Pearce wrote: >> The *correct* way to support an arbitrary rewind is to modify the >> outgoing channel from remote-curl to its protocol engine (client.in >> within the rpc_service method) to somehow request the protocol engine >> (aka git-send-pack or git-fetch-pack) to stop and regenerate the >> current request. > > That's a good idea! > >> Another approach would be to modify http-backend (and the protocol) >> to support an "auth ping" request prior to spooling out the entire >> payload if its more than an http.postBuffer size. Basically we >> do what the "Expect: 100-continue" protocol is supposed to do, >> but in the application layer rather than the HTTP/1.1 layer, so >> our CGI actually gets invoked. > > That's also quite a good idea, especially if it would be done in a way so > that it's certain that the same curl session will be reused, instead of > getting a potentially new curl session when using get_active_slot(). I think restarting the read by killing the protocol engine/client and starting again would be the easier of the two. Not just that, it would be neater than storing everything that the protocol engine has spewed out, like Martin's patch does. -- Cheers, Ray Chuan -- 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