tree 8ed2038c322af2d196c4751fd7f756376d230798
parent 7b77c9fd6df437aec46e429ade5ddaa407a92f57
author Willy Tarreau <w@1wt.eu> 1325974951 +0100
committer Willy Tarreau <w@1wt.eu> 1325974951 +0100
encoding latin1

BUG: http: tighten the list of allowed characters in a URI

The HTTP request parser was considering that any non-LWS char was
par of the URI. Unfortunately, this allows control chars to be sent
in the URI, sometimes resulting in backend servers misbehaving, for
instance when they interprete \0 as an end of string and respond
with plain HTTP/0.9 without headers, that haproxy blocks as invalid
responses.

RFC3986 clearly states the list of allowed characters in a URI. Even
non-ASCII chars are not allowed. Unfortunately, after having run 10
years with these chars allowed, we can't block them right now without
an optional workaround. So the first step consists in only blocking
control chars. A later patch will allow non-ASCII only when an appropriate
option is enabled in the frontend.

Control chars are 0..31 and 127, with the exception of 9, 10 and 13
(\t, \n, \r).