On Wed, May 13, 2015 at 2:03 AM, Christian Halstrick <christian.halstrick@xxxxxxxxx> wrote: > since a long time I am hitting very seldom errors when pushing with a > jgit client leading to "invalid channel 101" errors on client side. I > was always wondering why it was always the channel "101". Now I found > out with wireshark and it leads me to a question regarding the git > pack protocol [1] and the sideband capability [2] which I couldn't > answer from the technical docs. > > This is what happened: A client wants to push over http to a git > server. In the beginning they negotiated to use side-band-64k and > report-status capabilities. Everything works fine, Packfile data > transmission starts and sideband communication is ok. Now the server > hits a severe problem persisting the packfile and wants to stop the > transport. The git server hit's quotas on the filesystem usage and is > not allowed to persist that big file. My git server (I use a modified > gerrit server) intends to send back a packet line "0013error: ...". > But the client when reading that respond still thinks we should use > sideband communication and interpretes the "e" from "error" as > channel. The ascii code of "e" is the solution why it was always > "invalid channel 101" > > Here is my question: > - When exactly should sideband communication during a http based push > start and when should it end? If the client asked side-band-64k and report-status capabilities the server must use side-band to respond to the client. Its (obviously) assuming this. The bug here is JGit's ReceivePack/BaseReceivePack code not setting up the side-band-64k early enough for this failure report to be wrapped in it. > Especially in case of an error on the > server side. Is the server allowed to switch to non-sideband > communication under special conditions? No. The protocol has negotiated to use side-band-64k. That is what the client expects to see. In side-band-64k channel 2 is the "error" channel. Send a single packet on channel 2 carrying a single short text message and the entire stream is aborted at the client side after receiving this message. This is maybe what JGit should do in this case. > E.g. when the server responds > not with 200OK but with 413 (entity too large). No, you cannot use 413. > - Is responding with status code 200 mandatory when talking git pack > protocol? Am I allowed as git server to respond with status code 413 > and fill the body of the response with the status report? This was hashed out a long time ago. For the purposes of Git the HTTP 200 status code means the HTTP system successfully transported opaque data for Git, e.g. its like having no socket error from a socket routine. Any other HTTP status like 413 means the HTTP transport is busted. Its like getting EHOSTUNREACH or some other such errno from a socket function. I realize there are other interpretations for how applications should use HTTP status codes, and REST APIs often use them, but Git does not take that approach. FWIW I am glad you found this. I have been chasing this bug for years but couldn't really pin it down to anything. If its the "pack won't fit on local disk due to disk full" condition that narrows down the offending section of JGit considerably. > [1] https://raw.githubusercontent.com/git/git/master/Documentation/technical/pack-protocol.txt > [2] https://raw.githubusercontent.com/git/git/master/Documentation/technical/protocol-capabilities.txt -- 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