Resent-Date: Wed, 27 Mar 2019 16:30:52 +0000
Resent-Message-Id: <E1h9BS0-0004QR-CU@frink.w3.org>
To: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
References: <20141126195639.B3D5C181CE7@rfc-editor.org>
 <5476D0BC.70905@greenbytes.de>
 <CALaySJJh-9w2mnT9fV9dxaOJ_Tq=ipvV7nbNbEqY+g_6ppJjTg@mail.gmail.com>
 <723A86CD-6369-4A8A-B277-CBDA4439DCE9@gbiv.com> <55364CFE.1000007@gmx.de>
 <553654B5.3050801@treenet.co.nz>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <db8d567c-63c9-e711-5206-0a6daa449958@gmx.de>
Date: Wed, 27 Mar 2019 17:29:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <553654B5.3050801@treenet.co.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Technical Errata Reported] RFC7230 (4189)
Archived-At: <https://www.w3.org/mid/db8d567c-63c9-e711-5206-0a6daa449958@gmx.de>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On 21.04.2015 15:46, Amos Jeffries wrote:
> 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     =3D token
>>>        field-value    =3D *( field-content / obs-fold )
>>>        field-content  =3D field-vchar [ 1*( SP / HTAB ) field-vchar ]
>>>        field-vchar    =3D VCHAR / obs-text
>>>
>>>        obs-fold       =3D CRLF 1*( SP / HTAB )
>>>                       ; obsolete line folding
>>>                       ; see Section 3.2.4
>>>
>>> Corrected Text
>>> --------------
>>>        field-name     =3D token
>>>        field-value    =3D *( field-content / obs-fold )
>>>        field-content  =3D field-vchar [ 1*( SP / HTAB / field-vchar )
>>> field-vchar ]
>>>        field-vchar    =3D VCHAR / obs-text
>>>
>>>        obs-fold       =3D 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       =3D OWS CRLF RWS
>>
>> to
>>
>>    obs-fold       =3D 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 ]

Hm. Old thread :-)

So the question was whether

   "Content-Length:10\r\n"

that is the field value

   "10"

matches the corrected field-value ABNF:

>  field-value    =3D *( field-content / obs-fold ) >  field-content  =3D =
field-vchar [ 1*( SP / HTAB / field-vchar )
field-vchar ]
>  field-vchar    =3D VCHAR / obs-text
>  obs-fold       =3D OWS CRLF RWS

"1" matches field-content, so does "0". field-value is sequence of
field-value or obs-fold. So where is the issue?

Best regards, Julian