git pack protocol question: sideband responses in case of errors?

git pack protocol question: sideband responses in case of errors?

[Christian Halstrick]

Hi,

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? Especially in case of an error on the
server side. Is the server allowed to switch to non-sideband
communication under special conditions? E.g. when the server responds
not with 200OK but with 413 (entity too large).
- 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?

Ciao
  Chris

[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

Re: git pack protocol question: sideband responses in case of errors?

[Shawn Pearce]

On Wed, May 13, 2015 at 2:03 AM, Christian Halstrick
<christian.halstrick@gmail.com> 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