On Tue, 1 Dec 2009, Shawn O. Pearce wrote: > In the case of git-receive-pack requests, we might be uploading an > entire project to an empty repository on the remote side. This could > be 8 GiB worth of data if the project was something huge like KDE. > We can't assume that we should malloc 8 GiB of memory to buffer > the payload. True, fair enough. This was mostly a proof of concept of how this could be implemented, but with these comments for you, it's clear that this isn't a feasible solution at all. There's no acute need for it either. > 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(). > This unfortunately still relies on the underlying libcurl to not > discard the authentication data after that initial "auth ping". > But to be honest, I think that is a reasonable expectation. The > #@!*@!* library should be able to generate two requests back-to-back > to the same URL without needing to rewind the 2nd request. Yeah, as long as the same curl session is preserved, this should be no problem. // Martin -- 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