Re: [Technical Errata Reported] RFC7230 (4189)

[Amos Jeffries <[e-mail]>]

On 22/04/2015 1:13 a.m., Julian Reschke wrote:
> On 2015-02-06 23:32, Roy T. Fielding wrote:
>> ...
>> I looked at this originally and thought it made sense, but figured
>> I would have to check carefully first before responding ... and
>> then lost it.
>>
>> It should be verified as technical, but (like Julian) I think the
>> fix should be limited to field-content and obs-fold:
>>
>> Section: 3.2
>>
>> Original Text
>> -------------
>>       field-name     = token
>>       field-value    = *( field-content / obs-fold )
>>       field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
>>       field-vchar    = VCHAR / obs-text
>>
>>       obs-fold       = CRLF 1*( SP / HTAB )
>>                      ; obsolete line folding
>>                      ; see Section 3.2.4
>>
>> Corrected Text
>> --------------
>>       field-name     = token
>>       field-value    = *( field-content / obs-fold )
>>       field-content  = field-vchar [ 1*( SP / HTAB / field-vchar )
>> field-vchar ]
>>       field-vchar    = VCHAR / obs-text
>>
>>       obs-fold       = OWS CRLF RWS
>>                      ; obsolete line folding
>>                      ; see Section 3.2.4
>>
>> This fixes the problem examples and keeps obs-fold separate from
>> field-content.
>> It would be best if some other folks could confirm the above before
>> making
>> the errata official.
> 
> Looks right to me.
> 
> The one thing I'd change is to change
> 
>   obs-fold       = OWS CRLF RWS
> 
> to
> 
>   obs-fold       = OWS CRLF 1*( SP / HTAB )
> 
> to minimize the diff from the RFC.
> 
> Best regards, Julian
> 
> 

Seems to me that neither version allows matching of field-content
consisting of exactly 2 characters. eg. "Content-Length:10\r\n"

If I am reading that right the part inside the [] always matches 2+
characters at a time. So we have 1 character, or 3+ characters.

This pattern would fix:
 field-vchar [ *( SP / HTAB / field-vchar ) field-vchar ]


Amos