Re: [PATCH] Add ERR support to smart HTTP

> 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.