[PATCH v2 0/9] handle alternate charsets for remote http errors

From: Jeff King <peff@peff.net>
Date: May 22, 2014, 09:28 UTC
Message-ID: <20140522092824.GA14530@sigill.intra.peff.net>
In-Reply-To: <20140521102524.GA30301@sigill.intra.peff.net>

On Wed, May 21, 2014 at 06:25:24AM -0400, Jeff King wrote:

Show 14 quoted lines

> As of commit 426e70d (remote-curl: show server content on http errors,
> 2013-04-05), we relay any text/plain errors shown by the remote http
> server to the user. However, we were lazy back then and left this TODO
> in place:
> 
>        /*
>         * We only show text/plain parts, as other types are likely
>         * to be ugly to look at on the user's terminal.
>         *
>         * TODO should handle "; charset=XXX", and re-encode into
>         * logoutputencoding
>         */
> 
> This series actually implements that, along with a few other cleanups.

Here's a second version based on feedback from Kyle and Peter. Thanks both for your comments.

It drops the "tolower" patches, which are not used anymore, and makes the parsing of content-types and their parameters a bit more robust.

  [1/8]: test-lib: preserve GIT_CURL_VERBOSE from the environment
  [2/8]: t/lib-httpd: use write_script to copy CGI scripts
  [3/8]: t5550: test display of remote http error messages

    These three are the same as before.

  [4/8]: http: extract type/subtype portion of content-type

    Make our content-type matching more robust, both for the errors and
    for matching smart-http types.

  [5/8]: http: optionally extract charset parameter from content-type

    Feature work to support 7/8.

  [6/8]: strbuf: add strbuf_reencode helper

    Same as before (feature work to support 7/8).

  [7/8]: remote-curl: reencode http error messages

    The actual fix.

  [8/8]: http: default text charset to iso-8859-1

    This could be part of 5/8, but I floated it to the top of the heap
    to make it easier to discuss/adjust it.

-Peff