From: Joshua Juran Date: Mon, 06 Sep 2010 09:15:01 GMT Subject: Re: [PATCH] Add ERR support to smart HTTP Message-ID: In-Reply-To: <201009061049.38546.jnareb@gmail.com> 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 >> wrote: >>> On Mon, Sep 6, 2010 at 2:52 AM, Jakub Narebski >>> wrote: >>>> Ævar Arnfjörð Bjarmason writes: >>>> >>>>> On Sun, Sep 5, 2010 at 18:49, Ilari Liusvaara >>>>> 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