in `maybe_reserve` we have such code
```
let new = self.buf.capacity() - self.buf.len();
unsafe { grow_zerofill(&mut self.buf, new) }
```
the original behavior of `grow_zerofill` in such case cause
rewriting the memory behind the allocated vector.
``cmp::min(cap * 4, MAX_BUFFER_SIZE) - cap'' can underflow when
cap > MAX_BUFFER_SIZE. cap can exceed MAX_BUFFER_SIZE because
Vec::reserve aligns to powers of two.
Discovered by Matt Howard <themdhoward@gmail.com>
The results of benches/client.rs are below.
Before:
running 1 test
test bench_mock_hyper ... bench: 321609 ns/iter (+/- 18127)
After:
running 1 test
test bench_mock_hyper ... bench: 239319 ns/iter (+/- 29938)
This includes a custom BufReader, since the one in libstd doesn't allow
reading additional data into the buffer without consuming it. This is
required because some connections may send shorter packets, and so we
need to perform multiple reads. After each read, the contents of the
buffer are passed to httparse to see if have a valid message. If so, the
proper amount of bytes are consumed. The additional bytes are left in
the buffer since they are the beginning of the body.
The buffer in this BufReader also grows in size, compared to the libstd
which is sized once. This is because we start with a smaller buffer,
since the majority of messages will be able to include their head in a
packet or 2. Therefore, it's a wasteful performance hit to allocate the
maximum size for every message. However, some headers can be quite big,
and to allow for many of them to be set, we include a maximum size. Once
we've hit the maximum buffer size, and still haven't determined the end
of the headers, a HttpTooLargeError will be returned.
Closes#389
OlegTsyba