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. What do you think? -- Jakub Narebski Poland -- 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