On Sep 6, 2010, at 1:49 AM, Jakub Narebski wrote:
On Mon, Sep 6, 2010, Sitaram Chamarty wrote:
On Mon, Sep 6, 2010 at 6:34 AM, Sitaram Chamarty
<sitaramc@xxxxxxxxx> wrote:
On Mon, Sep 6, 2010 at 2:52 AM, Jakub Narebski <jnareb@xxxxxxxxx>
wrote:
Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
On Sun, Sep 5, 2010 at 18:49, Ilari Liusvaara
<ilari.liusvaara@xxxxxxxxxxx> wrote:
AFAIK, HTTP errors don't have descriptions printed.
I don't know if this applies here but HTTP error codes can come
with
any free-form \n-delimited string:
HTTP/1.1 402 You Must Build Additional Pylons
And you can also send more detailed description in the *body*
(and not
only HTTP headers) of HTTP response, though I don't know if git
does
that.
turns out all this was moot. It was *because* I was using something
other than "200 OK" that the user was not seeing the message.
Ilari's
patch just makes the message *look* better/cleaner, but I still have
to send it out with a "200 OK" status.
That was... a surprise :-)
From what I remember from smart HTTP discussion (during fleshing-out
the protocol/exchange details), the fact that errors from git are send
with "200 OK" HTTP status are very much conscious decision. But I
don't
remember *why* it was chosen this way. If I remember correctly it was
something about transparent proxies and caches... Is it documented
anywhere? Can anyone explain it?
I wasn't involved in the decision process, but I suspect it's because
HTTP is the transport layer to the Git application. It's the same
logic as trying to log in to a Web application with bogus credentials
and getting back a page (HTTP 200 OK) stating that the login failed.
As far as HTTP is concerned, the transaction succeeded.
Josh
--
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