Един прокси може успешно да извлече 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 като пълен файл.

Пазете низата жива, докато прехвърлянето приключи. Ако асинхронен запис в сокет след това препраща съдържанието му, пазете тези байтове живи, докато и този запис приключи. За големи отговори ограничена поточна схема е за предпочитане пред натрупването на цялото тяло.

Подобни статии