Fixed a bug in the header parsing code triggered when a continuation line
is a single space: the entire header field above it was ignored and the message terminated. This would normally only occur when cut-n-pasting from an xterm, but it revealed a bunch of other problems with the way we were looking for the request-line and header fields. I fixed it by rewriting the routines so that they would be more natural and not discard the error conditions, and introduced a new routine to buff.* for looking at the top of the input stream without changing it. The good news is that we now handle input lines robustly and do not puke when an extra CRLF is placed at the end of a POST request. The bad news is that I have found several places where we should be responding with 400 or 414 (Request-URI Too Long) messages when our input buffer fills-up, but we have no apparent mechanism for die'ing inside http_protocol.c. For now I am just letting the input be truncated, which is good enough for robust handling, but I would prefer to send an error response so that the webmaster can know about the invalid buffer-blowing attempts. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76971 13f79535-47bb-0310-9956-ffa450edef68
Please register or sign in to comment