Un proxy pode obter HTML correctamente e aínda así corromper unha imaxe mentres a copia nun búfer de C++. Antes de cambiar o protocolo do proxy, revise a función de devolución de recepción e o obxecto que se pasa como o seu contexto.

CURLOPT_WRITEDATA proporciona un punteiro á función de devolución de escritura. Sen unha función de devolución personalizada, o escritor predeterminado de libcurl espera un FILE *. Un enderezo como &response, onde response é un std::string, só ten sentido cando a súa función de devolución converte ese contexto de novo ao tipo previsto.

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

Rexiste ambas as metades no manipulador sinxelo utilizado para a transferencia:

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

A chamada append usa o reconto de bytes entregado. Os datos da función de devolución non rematan en nulo e unha imaxe pode conter bytes cero; medila con strlen perdería parte do corpo. Unha resposta tamén pode chegar mediante moitas chamadas de distintos tamaños.

Devolver o reconto de bytes consumidos acepta o fragmento. Devolver un reconto distinto aborta a transferencia cun erro de escritura. A protección de excepcións evita que un fallo de asignación escape a través do límite da función de devolución de C; quen chama aínda debe comprobar o resultado da transferencia antes de tratar response como un ficheiro completo.

Manteña a cadea viva ata que finalice a transferencia. Se unha escritura asíncrona no socket despois reenvía o seu contido, manteña eses bytes vivos ata que esa escritura tamén remate. Para respostas grandes, unha disposición de transmisión limitada é preferible a acumular todo o corpo.

Artigos relacionados