On Thu, Aug 29, 2013 at 12:40:16AM -0400, Jason Pyeron wrote: > > What would it mean to set it on the server? It is the size > > at which the client decides to use a "chunked" > > To tell the client... But the server in this case cannot tell it a useful size. Only "whatever you do, do not chunk". > Agreed. By then I hope to get our infrastructure team to address the proxies. > Liking the spool idea below. The other idea would be restrict the size of any > one transfer. (would that work if a given commit is large than the threshold???) I don't think you can do that elegantly. The packfile needs to come up as a whole, because the server is stateless. The best you could do is to split the packfile up into small updates of history, and then have the server receive each (and update the refs) incrementally. But even that isn't foolproof; it could be that a single large blob object is larger than the limit. > > If the server really insists on a content-length header, then > > we can't ever fix (2). But we could fix (1) by spooling the > > packfile to disk and then sending from there (under the > > assumption that you have way more temporary disk space than RAM). > > Hmmm. So if the server says, hey I have a borked infrastructure, please send me > a content length git could spool then. I'm not sure how the server would say that. It can return a 411, which it is currently doing, but the git client will have already discarded the data by that point. So it would have to come during one of the earlier responses (I guess an extra http header? I surely would not want to pollute the git protocol with such hackery). So let's imagine that we figure that part out, and now we can ship a 1G packfile up in a single POST by spooling it to disk. Do the proxies actually allow that? Or do they also have a max-size-per-post setting? If there is a maximum size, we can't get around that. And if it's small enough, there's no point in spooling, as we can just get by with tweaking http.postBuffer instead. -Peff -- 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