http: Detect end-of-header in read-header even when not on a packet boundary

[paulsnar]

The previous implementation would fail if \r\n\r\n weren't sent in a single packet, since it looks for it only on the boundaries of packets as returned by ev/read. This makes it look at least 4 bytes backwards – the performance difference should be minimal.

This was actually encountered using a derivation of spork/http with TLS support while communicating with an OpenWrt router (uhttpd), which output something similar to the test case, where the trailing \r\n was in its own TLS record, and read-header would skip over it. (Worse yet, with Transfer-Encoding: chunked, it also consumed the chunk data, because the closest \r\n\r\n was after the zero-length trailing chunk, making the body instead be empty.)

A test case is attached that illustrates this. Sorry if it's somewhat contrived.

[bakpakin]

Good catch, looks good to me. The /r/n/r/n search was written as just an optimization to avoid quadratic behavior so this addition should be perfectly fine.