"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > When --stateless-rpc is passed as a command line parameter to > upload-pack or receive-pack the programs now assume they may > perform only a single read-write cycle with stdin and stdout. > This fits with the HTTP POST request processing model where a > program may read the request, write a response, and must exit. > > When --advertise-refs is passed as a command line parameter only > the initial ref advertisement is output, and the program exits > immediately. This fits with the HTTP GET request model, where > no request content is received but a response must be produced. Is the idea to first run with --advertise-refs to get the set of refs, and then doing another, separate run with --stateless-rpc, assuming that the refs the other end advertised does not change in the meantime, to conclude the business? I suspect that two separate invocations on a (supposedly) single repository made back-to-back can produce an inconsistent response in verious situations (e.g. somebody pushing in the middle, or the same hostname served by more than one mirrors) and the other end can get confused. I do not think there is any way to avoid it, short of adding to the second request some "cookie" that allows the second requestee to verify that the request is based on what he would give to the requester if this request were the first step of the request made to him, iow, his state did not change in the middle since the first request was made (either to him or to the equivalent mirror sitting next to himm). I wouldn't worry too much about this if the only negative effect could be that the requestor's second request may result in an error, but I am wondering if this can be used to attack the requestee. -- 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