Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote: > On Mon, Sep 6, 2010 at 8:26 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > > That is, the following will trigger a correct error on the client: > > > > 200 OK > > Content-Type: application/x-git-upload-pack-advertisement > > > > 001e# service=git-upload-pack > > 0022ERR You shall not do this > > are those counts accurate for the specific example you show or just made up? > > It seems the first line has a count in hex that includes the newline > at the end, and the second one has a count in decimal that does not > include the newline nor even the 4-digits plus "ERR" Feh. I can't count. The first count is correct. The second count should also be 001e. I guess that should be obvious by just looking at the two lines, they are equal in length. :-) > > Likewise if you wanted to do this with receive-pack, replace upload > > with receive above and adjust the pkt-line lengths. > > ok... what about all the other service commands? like /info/refs? > What should I put there? The only other command that matters is info/refs. For smart clients, its what I said above. For dumb clients, you have to use some sort of HTTP error status that isn't 404. Dumb clients pre-1.6.6 use a curl error message buffer to print out an error. But they don't check the format of info/refs at all, and skip over garbage and/or interpret garbage as valid input. So we can't use a hack like "ERR blah" to even trigger a parsing failure. -- Shawn. -- 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