Subject: Re: #335, was: obs-fold

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Feb 2012 12:18:31 +1100

I think "field-value" would work...

On 01/02/2012, at 8:00 AM, Julian Reschke wrote:

> On 2012-01-30 01:14, Zhong Yu wrote:
>> p1 section 3.2.1.
>> 
>>    HTTP senders MUST NOT produce messages that include
>>    line folding (i.e., that contain any #field-content# that matches the
>>    obs-fold rule)
>> 
>> shouldn't that be
>> 
>>    HTTP senders MUST NOT produce messages that include
>>    line folding (i.e., that contain any #header-field# that matches the
>>    obs-fold rule)
>> 
>> instead?
>> 
>>      OWS            = *( SP / HTAB / obs-fold )
>>      BWS            = OWS
>> 
>>      header-field   = field-name ":" OWS field-value BWS
>>      field-name     = token
>>      field-value    = *( field-content / obs-fold )
>>      field-content  = *( HTAB / SP / VCHAR / obs-text )
> 
> Minimally, this is phrased confusingly. Not being sure what the best fix is, I opened a ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/335>
> 
> Best regards, Julian
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Zhong Yu <[email-masked]>
Date: Mon, 6 Feb 2012 20:21:11 -0600

Since OWS and BWS include obs-fold, that would allow generation of

1  GET / HTTP/1.1
2  Host:
3
4    www.example.com
5
6  Accept: *
7

where line 3 and 5 contain spaces.

The intention seems to be to forbid line folding anywhere in the
message head. CR/LF are already forbidden in request/response
line(specifically mentioned in RFC 2616). What's left is
'header-field'.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Feb 2012 15:52:06 +1300

On 07.02.2012 15:21, Zhong Yu wrote:
> On Mon, Feb 6, 2012 at 7:18 PM, Mark Nottingham wrote:
>>> Minimally, this is phrased confusingly. Not being sure what the 
>>> best fix is, I opened a ticket: 
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/335>
>>>

I'm getting Deja Vu all over again on this thread. Didn't we cover 
these same details with some specific header just last year?

It looks to me like this is a simple case of the draft ABNF not being 
kept up with the WG syntax goal decisions.

These seem to be the intended ABNF the text clauses are describing:

  OWS            = *( SP / HTAB )
  RWS            = 1*( SP / HTAB )
  BWS            = *( OWS / obs-fold )

Accepting that we could make these:

  header-field   = field-name ":" OWS BWS field-value
  field-name     = token
  field-value    = *( field-content BWS )
  field-content  = *( HTAB / SP / VCHAR )

Yes, there seems to be an overlap with the "OWS BWS" productions on 
header-field. But IMO its not a huge problem since its *optional* 
whitespace and does not matter whether the interpreter leaves the 
initial SP/HTAB as OWS or discards it as part of BWS.

AYJ