On 9/21/2022 6:24 PM, Matthew John Cheetham wrote:
> On 2022-09-19 09:21, Derrick Stolee wrote:
>> On 9/13/2022 3:25 PM, Matthew John Cheetham via GitGitGadget wrote:
>>> +
>>> + strvec_push(values, val);
>>> + http_auth.header_is_last_match = 1;
>>> + goto exit;
>>> + }
>>> +
>>> + /*
>>> + * This line could be a continuation of the previously matched header
>>> + * field. If this is the case then we should append this value to the
>>> + * end of the previously consumed value.
>>> + */
>>> + if (http_auth.header_is_last_match && isspace(*buf.buf)) {
>>> + const char **v = values->v + values->nr - 1;
>>
>> I suppose we expect leading spaces as critical to this header, right?
>
> Leading (and trailing) spaces are not part of the header value.
>
> From RFC 2616 section 2.2 regarding header field values:
>
> "All linear white space, including folding, has the same semantics as SP.
> A recipient MAY replace any linear white space with a single SP before
> interpreting the field value or forwarding the message downstream."
>
>>> + char *append = xstrfmt("%s%.*s", *v, (int)(size - 1), ptr + 1);
>>
>> We might have better luck using a strbuf, initializing it with the expected
>> size and using strbuf_add() to append the strings. Maybe I'm just prematurely
>> optimizing, though.
>
> This code path is used to re-join/fold a header value continuation, which is
> pretty rare in the wild (if at all with modern web servers).
I think the point is that I noticed that you removed the leading whitespace
in a header's first line, but additional whitespace after this first space
will be included in the concatenated content of the header value.
As long as that is the intention, then I'm happy here.
Thanks,
-Stolee
