I believe I've found a bug in the HTTP request header parsing logic.
// Header fields can be extended over multiple lines by preceding each extra line with at
// least one SP or HT.
if (endOfBufferPos > currentPos + newLineSize && (buffer[currentPos + newLineSize] == ' ' || buffer[currentPos + newLineSize] == buffer['\t']))
I think the issue is with the buffer[currentPos + newLineSize] == buffer['\t'] check. that buffer['\t'] should just be
'\t'. As it is right now,
'\t' is being evaluated to the decimal of tab (9) and that code is literally translating to buffer. So instead of checking to see if the first character of the next line is a tab (the space check
works just fine), it's actually checking to see if the first character of the next line matches the 9th character in the HTTP request.
For requests to simply 'http://webserver/', the HTTP request starts with GET / HTTP/1.1 buffer points to the 9th char in that request header which
is P. In IE, hitting F5 while viewing 'http://webserver/' sends up a 'Pragma: no-cache' header directly after the Host header, and as a result of the bug above, the Host header value ends up being evaluated to 184.108.40.2069:8081Pragma: no-cache
(which of course then results in the BadRequest exception).