git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed

From: Christian Halstrick <christian.halstrick@gmail.com>
To: Git <git@vger.kernel.org>, Shawn Pearce <sop@google.com>
Subject: git pack protocol question: sideband responses in case of errors?
Date: Wed, 13 May 2015 11:03:51 +0200	[thread overview]
Message-ID: <CAENte7j9De5Bqu2jDcmXQAxZheSGo+EntzsYUaen0N7cnuiCDQ@mail.gmail.com> (raw)

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

next             reply	other threads:[~2015-05-13  9:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  9:03 Christian Halstrick [this message]
2015-05-13 15:45 ` git pack protocol question: sideband responses in case of errors? Shawn Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAENte7j9De5Bqu2jDcmXQAxZheSGo+EntzsYUaen0N7cnuiCDQ@mail.gmail.com \
    --to=christian.halstrick@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sop@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).