W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #341: whitespace in request-lines and status-lines

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 14 Feb 2012 01:36:48 +1300
Message-ID: <4F3903E0.3020809@treenet.co.nz>
To: ietf-http-wg@w3.org
On 13/02/2012 8:16 p.m., Willy Tarreau wrote:
> Hi Mark,
> On Mon, Feb 13, 2012 at 03:10:06PM +1100, Mark Nottingham wrote:
>> Looking at this a bit more.
>> We can't use OWS or BWS here, because they both include obs-fold.
>> So, proposal:
>> Add a new construct:
>> SSP = SP /  1*BSP         ; preferred single space
>> BSP = ( HTAB / SP )       ; "bad" space
>> And change Request-Line and Status-Line to:
>>       Request-Line   = Method SSP request-target SSP HTTP-Version BSP CRLF
>>       Status-Line = HTTP-Version SSP Status-Code SSP Reason-Phrase BSP CRLF
>> With appropriate text cautioning against generation of BSP, but advising consumption of it.
>> Thoughts?
> FWIW, haproxy has never allowed HTABs nor multiple spaces here and still
> we dont get error reports. In fact the only times I catch this, it comes
> from a poorly-written attack script.

Ah. Thank you for that ammo. :)

> I don't think we should relax the parsing rules, and it seems like Amos and
> I were on the same line of "exactly matching" one SP.


I got argued into allowing multiple-SP while updating the parser on 
grounds of tolerance before a strict version went out. To my knowledge 
we have not had any bug reports about these internal SP either way, and 
no problems outside of testing software which made some effort to check 
the tolerance bounds.

The two problems I do know of are un-encoded SP within the URL from some 
Windows apps (not sure where its actually coming from, or if they are 
dead yet) and trailer SP bytes after the version string. The dev for 
those apps doing trailers have been fairly responsive towards fixing 
that at the client end already.

With the current RFC it is rather difficult to bring up evidence against 
OWS between "HTTP-version CRLF", despite being the common sense 
interpretation. The simple words "exactly match" would go a long way 
towards clarity there without any interoperability problem.

Received on Monday, 13 February 2012 12:37:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC