Re: header parsing, trailing OWS

Mark Nottingham wrote:
> That's taking it way too far, and would make many (most?) intermediaries 
> non-conformant. An intermediary can't and shouldn't have to mess with 
> headers that it doesn't care about. It's enough to say that such OWS is 
> to be ignored when a header is interpreted.

Right.

What's important is to clarify that leading and trailing whitespace is 
not part of the field value. (note that we're planning to change the 
ABNF fragments for header fields, so those will no longer contain the 
header name, colon, and surrounding whitespace; essentially what the *-v 
productions already show)

What follows from that, but doesn't necessarily need to spelled, is:

1) intermediaries may or may not throw them away

2) APIs may or may not throw them away

3) the semantics of header field definitions must not rely on the 
presence or absence of leading/trailing whitespace

WRT 3 we may want to add a specific section giving guidelines for 
defining new headers; these would also point out the importance of the 
#list rule, character encoding considerations and so on. I think most of 
this currently lives in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-07.html#rfc.section.4.2>, 
but it could be separated out into a new subsection.



BR, Julian

Received on Thursday, 8 October 2009 14:40:37 UTC