Shawn Pearce <spearce@xxxxxxxxxxx> writes: > On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Shawn Pearce <spearce@xxxxxxxxxxx> writes: >> >>> A stateless nonce could look like: >>> >>> nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key ) >>> >>> where site_key is a private key known to the server. It doesn't have >>> to be per-repo. >>> >>> receive-pack would then be willing to accept any nonce whose timestamp >>> is within a window, e.g. 10 minutes of the current time, and whose >>> signature verifies in the HMAC. The 10 minute window is important to >>> allow clients time to generate the object list, perform delta >>> compression, and begin transmitting to the server. >> >> Hmph, don't you send the "finally tell the other end" the sequence >> of "update this ref from old to new" and the packdata separately? > > No. The command list (triples of old, new, ref) is sent in the same > HTTP request as the pack data, ahead of the pack data. So its one > request. That is unfortunate. Would it be a major surgery to update the protocol not to do that, perhaps by moving the command list from 3 to 2 (the latter of which is not currently doing anything useful payload-wise, other than flushing a HTTP request early)? > Push on smart HTTP is 3 HTTP requests: > > 1) get advertisement > 2) POST empty flush packet to tickle auth (literally just "0000"). > 3) POST command list + pack > > The nonce can be sent server->client in 1, and client->server in 3. > >> I >> think we have a FLUSH in between, and the push certificate is given >> before the FLUSH, which you do not have to wait for 10 minutes. > > Nope I think you need to wait for the pack to generate enough to start > sending the pack data stream. Nothing forces the smart HTTP client to > push its pending buffer out. We wait for the pack data to either > finish, or overflow the in-memory buffer, and then start transmitting. > If your client needs a lot of time for counting and delta compression, > we aren't likely to overflow and transmit for a while. > > If you send a _lot_ of refs you can overflow, which will cause us to > transmit early. But we are talking about megabytes worth of (old, new, > ref) triplets to reach that overflow point. -- 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