Ta emot binära libcurl-svar i en C++ std::string

En proxy kan hämta HTML framgångsrikt och ändå förstöra en bild när den kopieras in i en C++-buffert. Innan du ändrar proxyprotokollet, kontrollera mottagningsåteranropet och objektet som skickas som dess kontext.

CURLOPT_WRITEDATA tillhandahåller en pekare till skrivåteranropet. Utan ett anpassat återanrop förväntar sig libcurls standardskrivare en FILE *. En adress som &response, där response är en std::string, är bara meningsfull när ditt återanrop kastar den kontexten tillbaka till den avsedda typen.

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

Registrera båda halvorna på det enkla handtaget som används för överföringen:

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

Anropet append använder det levererade bytantet. Återanropsdata är inte nollterminerad och en bild kan innehålla nollbytar; att mäta den med strlen skulle förlora en del av kroppen. Ett svar kan också anlända genom många återanrop av olika storlek.

Att returnera det förbrukade bytantet accepterar biten. Att returnera ett annat antal avbryter överföringen med ett skrivfel. Undantagsvakten hindrar ett allokeringsfel från att läcka ut över C-återanropsgränsen; anroparen måste ändå kontrollera överföringsresultatet innan response behandlas som en komplett fil.

Håll strängen vid liv tills överföringen är klar. Om en asynkron socket-skrivning sedan vidarebefordrar innehållet måste du hålla de byten vid liv tills den skrivningen också är klar. För stora svar är en begränsad streaminguppsättning att föredra framför att samla hela kroppen.