Re: p1: BWS

[Willy Tarreau <[e-mail]>]

On Thu, Apr 18, 2013 at 04:30:03PM +1200, Amos Jeffries wrote:
> On 18/04/2013 1:18 p.m., Mark Nottingham wrote:
> >p1 3.2.3 says:
> >
> >>    BWS is used where the grammar allows optional whitespace, for
> >>    historical reasons, but senders SHOULD NOT generate it in messages;
> >>    recipients MUST accept such bad optional whitespace and remove it
> >>    before interpreting the field value or forwarding the message
> >>    downstream.
> >   http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.3
> >
> >Throughout our specs, BWS is used at the end of header fields:
> >      header-field   = field-name ":" OWS field-value BWS
> >
> >and in transfer-codings:
> >      transfer-parameter = attribute BWS "=" BWS value
> >
> >and in Expect headers:
> >   expectation  = expect-name [ BWS "=" BWS expect-value]
> >                              *( OWS ";" [ OWS expect-param ] )
> >   expect-param = expect-name [ BWS "=" BWS expect-value ]
> >
> >and, finally, in auth-params on challenges and credentials:
> >   auth-param     = token BWS "=" BWS ( token / quoted-string )
> >
> >Is this whitespace really "bad" enough to MUST-require that intermediaries 
> >(including load balancers and other hardware!) remove it before forwarding 
> >the message?
> 
> For interoperability yes the whitespace is a bit problem. Its presence 
> subtly breaks any implementations looking for tokens with the strict 
> termination delimiter and also opens opportunities for problems related 
> to WS padding headers on maliciously crafted messages.

Agreed, but on the other hand, requiring that some intermediaries that do
not even use these fields to fix them can increase the risk of breaking
something between the client and the server. And since many of them will
not do it anyway, we'll end up with another MUST that is not respected,
so probably a SHOULD would be more appropriate ?

Willy