Re: Ambiguities in header-field rules (p1-messaging)

[Amos Jeffries <[e-mail]>]

On 18/08/11 19:58, Frank Mertens wrote:
> On 08/18/2011 05:16 AM, Amos Jeffries wrote:
>> On Wed, 17 Aug 2011 19:58:21 +0200, Frank Mertens wrote:
>>> Hi,
>>>
>>> I played around with the ABNF published by this WG and stumbled
>>> over some rough edges.
>>>
>>> Current rules:
>>>
>>> OWS = *( [ obs-fold ] WSP )
>>> header-field = field-name ":" OWS [ field-value ] OWS
>>> field-value = *( field-content / OWS )
>>> field-content = *( WSP / VCHAR / obs-text )
>>>
>>> Problems:
>>>
>>> - field-value and field-content match the empty symbol,
>>> which requires searching for the longest match, which is costly
>>> (and confusing for the human reader)
>>> - because field-value matches the empty symbol claiming it optional
>>> in header-field allows ambiguous productions of same length
>>> (with or without field-value of zero length?)
>>>
>>> Suggested improvement:
>>>
>>> field-value = 1*( field-content OWS )
>>> field-content = 1*( VCHAR / WSP / obs-text )
>>>
>>> Best Regards,
>>> Frank Mertens.
>>
>>
>> The OWS on header-field remains ambiguous as well.
>>
>> Also, with WSP being in field-content there is the possibility of
>> header-field matching:
>>
>> field-name ":" [ obs-fold ] 1*( WSP OWS ) OWS
>>
>> Nasty. But section 3.2 comes to the rescue:
>> "The field value does not include any leading or trailing white space"
>> and
>> "HTTP/1.1 senders MUST NOT produce messages that include line folding"
>>
>> So OWS in the field-value ABNF appears to be invalid in several ways
>> going by the text.
>>
>>
>> Perhapse this would be better:
>>
>> header-field = field-name ":" [ WSP ] BWS [ field-value ]
>> field-value = 1*( field-content BWS )
>> field-content = 1*( VCHAR / WSP / obs-text )
>>
>>
>>
>>
>> Nit: section 1.2.2 currently says:
>>
>> "Multiple OWS octets that occur within field-content
>> SHOULD be replaced with a single SP before interpreting the field
>> value or forwarding the message downstream."
>> ...
>> "Multiple RWS octets that occur within field-content SHOULD be
>> replaced with a single SP before interpreting the field value or
>> forwarding the message downstream.
>> "
>>
>> When there is no OWS or RWS in the field-content ABNF.
>>
>> I think both should say header-field instead of field-content. Or
>> maybe drop the "within field-content" condition to make it general.
>>
>>
>> AYJ
>>
>>
>
> Yes, maybe we should also have a strict version of the grammar.
> But for now, I'm happy with a working tolerant one;)
> Replacing OWS by BWS would also disable support for line folding.

BWS accepts input which is folded. Look at its description in section 1.2.2

section 3.2 already prohibits folding with a MUST NOT which I quoted.

AYJ