Fix URI parsing for non-std 'space' chars
Fix URI parsing for non-std 'space' chars

URI parsing could be confused by the very permissive 'space'
interpretation of "htp_is_space()". This lead to cases where some
space like characters such as 0x0c would end the URI, even though
in reality the URI didn't end.

As the permissive parsing is sometimes necessary (many servers allow
more than just the real space 0x20 RFC's specify), this patch addresses
this problem as follows:

An initial pass of the request line looks just for the real space
(0x20) but does also detect when non-std 'space' chars were present.
In the common case this will will be the only pass as the non-std
chars are very uncommon.

If this parsing didn't lead to a parsed URI _and_ one or more of
the non-std chars were found, then we run a 2nd pass with much
more permissive parsing which is effectively the same as the old
behaviour.

In either case a warning is generated for the presense of the non-
std chars.

Addionally, a similar warning is generated with the method and
the URI are separated by such characters.

Reported-by: Darien Huss / Emerging Threats.

wxsBSD/libhtp,OISF/libhtp,montekki/libhtp,OISF/libhtp,glongo/libhtp,wxsBSD/libhtp,wxsBSD/libhtp,glongo/libhtp,wxsBSD/libhtp,OISF/libhtp,wxsBSD/libhtp,OISF/libhtp,montekki/libhtp,OISF/libhtp,wxsBSD/libhtp,glongo/libhtp,montekki/libhtp,montekki/libhtp,glongo/libhtp,OISF/libhtp,glongo/libhtp,OISF/libhtp,montekki/libhtp,glongo/libhtp,glongo/libhtp,montekki/libhtp,wxsBSD/libhtp,montekki/libhtp