A proxy sikeresen letöltheti a HTML-t, és közben mégis tönkretehet egy képet, miközben C++ puffere másolja. Mielőtt megváltoztatná a proxy protokollját, ellenőrizze a fogadó visszahívást és a kontextusként átadott objektumot.

CURLOPT_WRITEDATA mutatót ad az író visszahívásra. Egyéni visszahívás nélkül a libcurl alapértelmezett írója egy FILE *-t vár. Egy olyan cím, mint &response, ahol a response egy std::string, csak akkor van értelme, ha a visszahívása visszaalakítja ezt a kontextust a szándékolt típusra.

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;
}

Regisztrálja mindkét felét az átvitelhez használt egyszerű kezelőn:

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

Az append hívás a megadott bájtszámot használja. A visszahívási adatok nem null-termináltak, és egy kép tartalmazhat nulla bájtokat; strlen-nel mérve a test egy része elveszne. A válasz sok, különböző méretű visszahívás során is megérkezhet.

Az elfogyasztott bájtszám visszaadása elfogadja a darabot. Egy másik szám visszaadása írási hibával megszakítja az átvitelt. A kivételőr megakadályozza, hogy egy allokációs hiba átjusson a C visszahívás határán; a hívónak továbbra is ellenőriznie kell az átvitel eredményét, mielőtt a response-t teljes fájlnak tekinti.

Tartsa életben a karakterláncot, amíg az átvitel be nem fejeződik. Ha egy aszinkron socket-írás továbbítja a tartalmát, tartsa életben azokat a bájtokat, amíg az az írás is be nem fejeződik. Nagy válaszok esetén a korlátozott streamelési elrendezés előnyösebb a teljes test felhalmozásánál.

Kapcsolódó cikkek