Прокси може успешно да преузме 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 третира као потпуну датотеку.

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

Повезани чланци