Re: Returning error message from custom smart http server

[Jeff King <peff@peff.net>]

On Mon, May 19, 2014 at 06:12:10PM +1000, Bryan Turner wrote:

> For starters, to return an error message, your status must be 200 OK.
> You can't return any other status code or Git will interpret your
> error as some form of _HTTP_ error rather than a _git_ error.

As of git v1.8.3, git will show text/plain content sent along with a
a non-200 HTTP code.

However, it does this _only_ for the initial refs fetch (along with
several other error-reporting niceties, including specifically handling
HTTP 401s). The thinking was that the interesting smart-http errors
happen on that initial contact (e.g., failure to login, access denied,
etc). Errors at the HTTP level that happen later during POST requests
mean that the server is misconfigured or broken somehow, and should be
rare. That's the theory anyway.

In the original poster's example, it looks like the server is rejecting
the push with an HTTP 401 during the POST call, after the initial ref
advertisement. This is non-ideal, because it means the client may have
gone to significant work to generate the packfile. It should instead
reject it as soon as it sees a request for
".../info/refs?service=git-receive-pack". Current git clients will
prompt for errors, and will also show the text/plain content.

> - Set the content type to "application/x-<service>-advertisement"
> (e.g. "application/x-git-receive-pack-advertisement") (Not all command
> line Git versions require this, but JGit does)

A side note, but command-line Git cares about the content-type since
v1.8.1.5.

> [...how git's ERR lines work...]

Your description seemed accurate from my brief read. Sending ERR lines
goes back much further. However, for a 401, I think they really want to
send the HTTP code (and at the right time), so that the client can
recognize this, gather credentials from the user, and try again.

-Peff