Um proxy pode obter HTML com sucesso e ainda corromper uma imagem ao copiá-la para um buffer C++. Antes de alterar o protocolo do proxy, verifique a função de retorno de receção e o objeto passado como seu contexto.

CURLOPT_WRITEDATA fornece um ponteiro para a função de retorno de escrita. Sem uma função de retorno personalizada, o escritor predefinido do libcurl espera um FILE *. Um endereço como &response, onde response é um std::string, só faz sentido quando a sua função de retorno converte esse contexto de volta ao tipo pretendido.

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

Registe ambas as metades no handle simples utilizado para a transferência:

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

A chamada append utiliza a contagem de bytes entregue. Os dados da função de retorno não terminam em nulo e uma imagem pode conter bytes zero; medi-la com strlen perderia parte do corpo. Uma resposta também pode chegar através de muitas chamadas de tamanhos diferentes.

Devolver a contagem de bytes consumidos aceita o fragmento. Devolver uma contagem diferente aborta a transferência com um erro de escrita. A proteção de exceções impede que uma falha de alocação escape através do limite da função de retorno C; quem chama ainda deve verificar o resultado da transferência antes de tratar response como um ficheiro completo.

Mantenha a string viva até a transferência terminar. Se uma escrita assíncrona no socket depois encaminhar o seu conteúdo, mantenha esses bytes vivos até essa escrita também terminar. Para respostas grandes, uma disposição de streaming limitada é preferível a acumular todo o corpo.

Artigos relacionados