On May 23, 2014, at 13:12, Jeff King wrote:
Show 49 quoted lines
> On Thu, May 22, 2014 at 03:52:21PM -0700, Kyle J. McKay wrote:
>
>>> +static void extract_content_type(struct strbuf *raw, struct
>>> strbuf *type)
>>> +{
>>> + const char *p;
>>> +
>>> + strbuf_reset(type);
>>> + strbuf_grow(type, raw->len);
>>> + for (p = raw->buf; *p; p++) {
>>> + if (isspace(*p))
>>> + continue;
>>> + if (*p == ';')
>>> + break;
>>> + strbuf_addch(type, tolower(*p));
>>> + }
>>> +}
>>> +
>>
>> This will parse invalid content types as valid. Probably not
>> important
>> since the producer of an invalid content type shouldn't be
>> depending on any
>> particular behavior by the consumer of such a type, but I think it
>> warrants
>> a note in the comment block, perhaps something like:
>>
>> * Note that an invalid content-type may be converted to a valid one
>>
>> or some such.
>
> Yeah, that is intentional based on our earlier discussion (this
> function
> started as "normalize_content_type" :) ). I think it's not a big deal,
> but agree it's worth a comment. Like:
>
> diff --git a/http.c b/http.c
> index 4edf5b9..6bfd093 100644
> --- a/http.c
> +++ b/http.c
> @@ -911,8 +911,14 @@ static CURLcode curlinfo_strbuf(CURL *curl,
> CURLINFO info, struct strbuf *buf)
> * spaces suppressed, all letters lowercased, and no trailing ";"
> * or parameters.
> *
> + * Note that we will silently remove even invalid whitespace. For
> + * example, "text / plain" is specifically forbidden by RFC 2616,
> + * but "text/plain" is the only reasonable output, and this keeps
> + * our code simple.