Shawn Pearce <spea...@spearce.org> writes:
> On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> Shawn Pearce <spea...@spearce.org> 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
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.
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html