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

On 08/18/2011 10:35 AM, Amos Jeffries wrote:
> 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
>

YES, you are right and I fully agree with your ABNF rules.
I was misreading BWS as WS yesterday. Anyone around here, that can make the
changes?

FM

Received on Thursday, 18 August 2011 13:10:55 UTC