On Mon, Sep 6, 2010 at 2:19 PM, Jakub Narebski <jnareb@xxxxxxxxx> 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? > > Nevertheless I think it would be a good idea to make *client* more > accepting, which means: > 1. Printing full HTTP status, and not only HTTP return / error code; > perhaps only if it is non-standard, and perhaps only in --verbose > mode. > 2. If message body contains ERR line, print error message even if the > HTTP status was other than "200 OK". To be "generous in what you > receive" (well, kind of). > 3. In verbose mode, if body of HTTP error message (not "HTTP OK") > exists and does not contain ERR line (e.g. an error from web server), > print it in full (perhaps indented). > > I think that neither of the above would lead to leaking sensitive > information. I didn't understand this bit about leaking info. If the bits are coming into my machine I know what they are anyway (or am able to find out easily enough, even if git itself isn't showing them to me). Where's the leak? And I do see the point that Joshua made that the 200 reflects HTTP status, not git status. Makes sense, and answers my original question... regards sitaram -- 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