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

Hi Amos,

On Tue, Feb 14, 2012 at 01:36:48AM +1300, Amos Jeffries wrote:
> >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. :)

You're welcome :-)

(...)
> 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.

OK. I've never encountered these ones except in attacks. For instance,
here with a capture of such a failure on my reverse proxy :

  [02/Feb/2012:00:47:19.447] frontend http-in (#1): invalid request
  src 88.191.95.247, session #189428, backend <NONE> (#-1), server <NONE> (#-1)
  HTTP internal state 26, buffer flags 0x00809002, event #12
  request length 222 bytes, error at position 55:
 
  00000  GET //wp/wp-content/themes/automotive-blog-theme/Quick Cash Auto/timth
  00070+ umb.php HTTP/1.1\r\n
  00088  Accept: */*\r\n
  00101  Accept-Language: en-us\r\n
  00125  Accept-Encoding: gzip, deflate\r\n
  00157  User-Agent: Mozilla/5.0\r\n
  00182  Host: demo.1wt.eu\r\n
  00201  Connection: Close\r\n
  00220  \r\n
 
It was rejected because of the embedded space :-)

> 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.

That was my point too. Mark, would you accept to update the wording when
two implementers feel like there's a risk of not being careful enough with
current wording ?

Regards,
Willy

Received on Monday, 13 February 2012 12:59:12 UTC