Станислав Макаров

В этом же примере всё и написано, чуть выше. Цитирую:

// Set up the variables that receive the result of the asynchronous
// operation. The error code is set to would_block to signal that the
// operation is incomplete. Asio guarantees that its asynchronous
// operations will never fail with would_block, so any other value in
// ec indicates completion.
ec = boost::asio::error::would_block;
std::size_t length = 0;

Обратите внимание на "so any other value in ec indicates completion". Нам показывают, что начальное значение ec выставляется в would_block и используется как маркер того, что мы ЕЩЁ ничего не записали в переменную ec в обработчике handle_receive. Иными словами, как маркер того, что handle_receive ещё не выполнился. Когда выполнится - то, согласно интерфейсу Asio, в него прилетит что-либо, отличное от would_block, что и будет им записано в ec. Это и будет условием выхода из цикла.

Цикл здесь организован, чтобы дождаться выполнения конкретно асинхронной операции чтения.
Вам может показаться, что асинхронная операция здесь запускается только одна, но это не так, ведь есть ещё срабатывание таймера deadline_. Из чего можно заключить, что каждый вызов run_once может запустить либо обработчик handle_receive, либо check_deadline (напомню, что run_once прокачивает только один вызов какого-либо обработчика в очереди).

async_receive:

The receive operation may not receive all of the requested number of bytes. Consider using the async_read function if you need to ensure that the requested amount of data is received before the asynchronous operation completes.

Но т.к. вы всё равно заранее не знаете, сколько байт вам нужно прочитать, я не вижу проблемы в поведении async_receive. Вам нужно отслеживать состояние вашего протокола (в вашем случае - HTTP) и понимать, когда нужно подождать ещё данных, а когда уже всё пришло.