Re: [PATCH] Add ERR support to smart HTTP

[Jakub Narebski <jnareb@gmail.com>]

On Mon, Sep 6, 2010, Sitaram Chamarty wrote:
> On Mon, Sep 6, 2010 at 6:34 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> On Mon, Sep 6, 2010 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>>
>>>> On Sun, Sep 5, 2010 at 18:49, Ilari Liusvaara
>>>> <ilari.liusvaara@elisanet.fi> 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