Re: [PATCH v5 4/5] config: improve support for http.<url>.* settings

[Eric Sunshine <sunshine@sunshineco.com>]

On Mon, Jul 15, 2013 at 5:51 AM, Kyle J. McKay <mackyle@gmail.com> wrote:
> Improve on the http.<url>.* url matching behavior by first
> normalizing the urls before they are compared.
>
> diff --git a/http.c b/http.c
> index 758e5b1..d04386e 100644
> --- a/http.c
> +++ b/http.c
> @@ -169,6 +169,210 @@ static void process_curl_messages(void)
>  }
>  #endif
>
> +static int append_normalized_escapes(struct strbuf *buf,
> +                                    const char *from,
> +                                    size_t from_len,
> +                                    const char *esc_extra,
> +                                    const char *esc_ok)
> +{
> +       /*
> +        * Append to strbuf buf characters from string from with length from_len

s/from string from/from string/

> +        * while unescaping characters that do not need to be escaped and
> +        * escaping characters that do.  The set of characters to escape (the
> +        * complement of which is unescaped) starts out as the RFC 3986 unsafe
> +        * characters (0x00-0x1F,0x7F-0xFF," <>\"#%{}|\\^`").  If esc_extra
> +        * is not NULL, those additional characters will also always be escaped.
> +        * If esc_ok is not NULL, those characters will be left escaped if found
> +        * that way, but will not be unescaped otherwise (used for delimiters).
> +        * If a %-escape sequence is encountered that is not followed by 2
> +        * hexadecimal digits, the sequence is invalid and false (0) will be
> +        * returned.  Otherwise true (1) will be returned for success.
> +        *
> +        * Note that all %-escape sequences will be normalized to UPPERCASE
> +        * as indicated in RFC 3986.  Unless included in esc_extra or esc_ok
> +        * alphanumerics and "-._~" will always be unescaped as per RFC 3986.
> +        */