Примање бинарни libcurl одговори во C++ std::string

Прокси може успешно да преземе HTML, а сепак да расипе слика додека ја копира во C++ бафер. Пред да го промените протоколот на проксито, проверете го повратниот повик за примање и објектот предаден како негов контекст.

CURLOPT_WRITEDATA дава покажувач кон повратниот повик за запишување. Без прилагоден повратен повик, стандардниот запишувач на libcurl очекува FILE *. Адреса како &response, каде response е std::string, има смисла само кога вашиот повратен повик го претвора тој контекст назад во предвидениот тип.

static size_t receive(char* data, size_t size,
                      size_t count, void* context) {
    const size_t bytes = size * count;
    auto* body = static_cast<std::string*>(context);
    try {
        body->append(data, bytes);
    } catch (...) {
        return 0;
    }
    return bytes;
}

Регистрирајте ги двете половини на едноставната рачка што се користи за преносот:

std::string response;
curl_easy_setopt(handle, CURLOPT_WRITEFUNCTION, receive);
curl_easy_setopt(handle, CURLOPT_WRITEDATA, &response);

Повикот append го користи доставениот број на бајти. Податоците од повратниот повик не се завршуваат со нула и сликата може да содржи нулти бајти; мерењето со strlen би изгубило дел од телото. Одговорот може да пристигне и преку многу повици со различни големини.

Враќањето на потрошениот број на бајти го прифаќа делот. Враќањето на различен број го прекинува преносот со грешка при запишување. Заштитникот од исклучоци спречува неуспех при распределба на меморија да избега преку границата на C повратниот повик; повикувачот сепак мора да го провери резултатот од преносот пред да го третира response како целосна датотека.

Држете ја низата жива додека преносот не заврши. Ако асинхроно пишување на сокет потоа го препрати неговото содржина, држете ги тие бајти живи додека и тоа пишување не заврши. За големи одговори, ограничен распоред на стримување е попожелен од натрупување на целото тело.