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 -- 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