Bug: BadRequest exception when parsing HTTP Request headers

Jun 12, 2009 at 11:14 PM


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[9]. 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[9] 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 no-cache  (which of course then results in the BadRequest exception).



Jun 15, 2009 at 10:43 PM

How do you prefer these sort of bug be submitted? It is best to just post a discussion item, do you prefer a I create an issue or do you prefer I actually submit a patch?