时间戳

首页 > 解决方案 > 在 VM 上运行时 cURL MIME 数据损坏

c - 在 VM 上运行时 cURL MIME 数据损坏

问题描述

我遇到了一个看起来很奇怪的问题。

首先，它只发生在运行在 Windows 10 主机之上的 VMWare 上的 Ubuntu 18.04 上。

我正在使用 CURL 发送一个多部分请求，一旦传递给 curl_mime_data 的数据大小超过一定数量，它就会以某种偏移量被开头覆盖的方式损坏，例如，“abcdefgh”将变为'abcabcabc'。

我在接收方和发送方的 Wireshark 中都看到了这些损坏的数据，因此确实是以这种方式发送的。我设法使用下面的玩具程序重现了该行为：

#include <fstream>
#include <iostream>
#include <memory>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>
#include <assert.h>
#include <curl/curl.h>

int main(int argc, char **argv)
{
  curl_global_init(0);
  CURL *curl = curl_easy_init();
  curl_mime *form = nullptr;
  curl_mimepart *field = nullptr;
  CURLcode res = CURLE_OK;

  form = curl_mime_init(curl);

  std::ifstream t("test.json");
  if (!t.good())
  {
    return 1;
  }
  std::string str;
  t.seekg(0, std::ios::end);
  str.reserve(t.tellg());
  t.seekg(0, std::ios::beg);

  str.assign(std::istreambuf_iterator<char>(t), std::istreambuf_iterator<char>());

  size_t totalsize = 0;
  {
    field = curl_mime_addpart(form);
    res = curl_mime_data(field, (const char *)str.c_str(), str.size());
    {
      FILE *f = fopen("out.json", "w");
      fprintf(f, "%s", str.c_str());
      fclose(f);
    }
    res = curl_mime_name(field, "response");
    assert(res == CURLE_OK);
  }

  curl_easy_setopt(curl, CURLOPT_TIMEOUT, 10);
  curl_easy_setopt(curl, CURLOPT_URL, "http://1.2.3.4");
  curl_easy_setopt(curl, CURLOPT_MIMEPOST, form);

  res = curl_easy_perform(curl);
  assert(res == CURLE_OK);

  curl_mime_free(form);
  curl_easy_cleanup(curl);
  curl_global_cleanup();
  return 0;
}

在这里，我正在读取一个示例文件以从磁盘发送并在传递给 curl 进行比较之前将其刷新回来。在这一点上，没有区别，但是正在发送的值与原始文件的内容不同。

如开头所述，这只发生在非常特定的环境中，即 Windows 10 上 VMWare Workstation 12 上的 Ubuntu 18.04。就此而言，上述 ubuntu 的两个不同实例。运行时不会发生这种情况：

我有点不知道在哪里看或可能导致这种情况的原因。我正在使用 libcurl 7.56 和 gcc 7.3.0

你能给我一些想法吗？我使用 libcurl 错了吗？还有什么可能是错误的或值得尝试的？

更新

刚刚在 Ubuntu 16.04 上测试过，数据也损坏了。至于我正在使用的数据，这里是原始 json 文件https://www.dropbox.com/s/gfk0b61tyel68wu/test.json?dl=0以及我从 Wireshark 获得的内容https://www.dropbox .com/s/dwlzwhn755c51cf/bad.json?dl=0问题从第779行开始。（这是由json生成器创建的随机json，不是真实数据）

更新 2

这似乎是 curl 7.56 的问题。看起来，不管它是什么，它已经在 curl 7.61.1 中修复（此时最新的）。甚至进一步的调查表明，它被修复的确切提交是 5f9e2ca09b57d82baf239039835b3b06dc41bbc5

标签： clibcurlmultipartubuntu-18.04

解决方案

正如我所发现的，这个特定的错误已在此提交“mime：修复内容阅读器以正确处理 >16K 数据”中得到修复

推荐阅读