Re: header parsing, trailing OWS

OK, I agree I took it a bit far.  I guess the key point is it must be 
clear that since it is valid to ignore OWS, therefore implementors must 
not rely on OWS being preserved through the request / response chain.  I 
guess that's what you mean by 3 below?  I think it's a broader 
requirement than just the semantics of the field definition.

Perhaps some notes to implementors then, just so the issue is brought to 
their attention.  For instance if we don't require OWS to be stripped by 
servers say parsing script output, and don't require it to be stripped 
by intermediaries, but we do require it to be ignored by anything 
interpreting the value, then I can see problems where people will deploy 
systems that effectively rely on OWS, but problems aren't found in 
testing because the OWS is by default preserved by intermediaries and 
UAs through to API clients, and not checked-for in client-side or 
server-side scripts (say).

Regards
Adrien


Julian Reschke wrote:
> 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

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Thursday, 8 October 2009 21:53:35 UTC