23

我正在编写一个通过 cURL 查询社交媒体 API 的 Python 应用程序。我查询的大多数不同服务器（Google+、Reddit、Twitter、Facebook 等）都有 cURL 抱怨：

附加的东西不好 transfer.c:1037: 0 0

不寻常的是，当应用程序第一次启动时，每个服务的响应都会抛出一次或两次这一行。几分钟后，这条线会出现几次。显然 cURL 正在识别它不喜欢的东西。大约半小时后，服务器开始超时，这条线重复了几十次，所以它显示出一个真正的问题。

我该如何诊断？我尝试使用 Wireshark 捕获请求和响应标头以搜索可能导致 cURL 抱怨的异常，但是对于所有 Wireshark 的复杂性，似乎没有一种方法可以仅隔离和显示标头。

这是代码的相关部分：

output = cStringIO.StringIO()
c = pycurl.Curl()
c.setopt(c.URL, url)
c.setopt(c.USERAGENT, 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0')
c.setopt(c.WRITEFUNCTION, output.write)
c.setopt(c.CONNECTTIMEOUT, 10) 
c.setopt(c.TIMEOUT, 15) 
c.setopt(c.FAILONERROR, True)
c.setopt(c.NOSIGNAL, 1)

try:
    c.perform()
    toReturn = output.getvalue()
    output.close()
    return toReturn

except pycurl.error, error:
    errno, errstr = error
    print 'The following cURL error occurred: ', errstr
4

3 回答 3

29

我 99.99% 确定这实际上不在任何 HTTP 标头中，而是stderr由libcurl. 这可能发生在您记录标题的过程中，这就是您感到困惑的原因。

无论如何，快速搜索"additional stuff not fine" curl transfer.c发现描述是源的最近更改：

curl_readwrite：删除调试输出

前段时间为了调试目的添加了文本“其他东西不好”文本，但它并没有真正帮助任何人，并且出于某种原因，一些 Linux 发行版提供了仍然存在调试信息的 libcurl，因此（太多）用户阅读此信息。

所以，这基本上是无害的，你看到它的唯一原因是你得到了一个libcurl启用了完整调试日志的构建（可能来自你的 linux 发行版）（尽管curl作者认为这是一个坏主意）。所以你有三个选择：

  1. 忽略它。
  2. 升级到更高版本的libcurl.
  3. libcurl在没有调试信息的情况下重建。

您可以查看libcurl来源transfer.c（如上链接）以尝试了解curl抱怨的内容，并可能在大约同一时间在邮件列表中查找主题 - 或者只是通过电子邮件发送列表并询问。

但是，我怀疑这实际上可能与真正的问题根本无关，因为您甚至从一开始就看到了这一点。

这里有三件明显的事情可能会出错：

  1. curl 中的错误，或者您使用它的方式。
  2. 您的网络设置有问题（例如，您的 ISP 会因为您在 30 分钟内建立过多的传出连接或使用过多的字节而将您中断）。
  3. 您正在做的事情是让服务器认为您是垃圾邮件发送者/DoS 攻击者/无论他们正在阻止您。

第一个实际上似乎最不可能。如果你想排除它，只需捕获你发出的所有请求，然后编写一个简单的脚本，使用其他库来重放完全相同的请求，看看你是否得到相同的行为。如果是这样，问题显然不在于您如何提出请求。

您可能能够根据时间区分情况 2 和 3。如果所有服务同时超时——尤其是当您在不同时间开始点击它们时它们都超时（例如，您在 Facebook 后 15 分钟开始点击 Google+，但它们都在您点击 Facebook 后 30 分钟超时） ，肯定是情况2。如果不是，可能是情况3。

如果你排除了所有这三个，那么你可以开始寻找其他可能出错的事情，但我会从这里开始。

或者，如果您告诉我们更多关于您的应用程序的确切功能（例如，您是否尝试以尽可能快的速度一遍又一遍地访问服务器？您是否尝试代表大量不同的用户进行连接？您使用的是dev 密钥或最终用户应用程序密钥？等），其他对这些服务有更多经验的人可能会猜测。

于 2012-12-18T23:52:50.133 回答
4

我不同意这一点 - 尝试通过 BIGIP LTM 外部 VIP 地址呼叫网站时，我收到相同的消息。

例如：

我将网站称为http://11five.10.10.10/index.html（在这种情况下 IP 地址是随机的）。BIG F5 应该通过与虚拟服务器关联的池对两个内部 Web 服务器（17two.20.0.10 和 17two.20.0.11）的流量进行负载平衡。

在这种情况下，从外部源（内部客户端）到 TCP 80 上的 VIP 地址的请求应该在两个 Web 服务器之间循环。我发现所有服务器都收到了一个初始的 SYN 数据包，而从来没有收到 SYN-ACK。

如果我坐在真实服务器所在的本地子网内的终端上，我可以“wget”index.html 网页——从 17two.20.0.11 到http://17two.20.0.10 }/index.html。

来自外部，我收到 *additional stuff not fine transfer.c:1037 0 0 消息。

你说得对，它是 libcurl 库的旧版本中 CURL 的内置调试机制，但我不同意下面的说法；

A bug in curl, or the way you're using it.
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes).
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you.

造成这种情况的原因是环境中的网络问题，IE .. Web 服务器无法将流量返回到原始源，因此显示一两个错误，请求标头和响应有问题从网络服务器。

在这种情况下，我会选择说原始问题更有可能是因为当我对来自本地子网中的测试主机的原始请求使用不同的 URI 执行 curl 时，我可以很好地检索 index.html 网页。这意味着服务器正在侦听和接受使用 FQDN 和服务器短名称的连接。

我相信这个错误表明 curl 收到了一个不确定的响应，因此会产生上述错误。如果没有开发 curl 或阅读源代码，我无法进一步评论。

任何质疑这种逻辑的额外回应都将受到欢迎——所有这些都是为了学习新事物。

安迪

于 2013-04-21T09:40:24.253 回答
0

确认

curl 中的错误，或者您使用它的方式。

系统信息：Linux alt 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

我更新了 curl 库和连续消息（在 twitter rest api 测试中被捕获）

  • 附加的东西不好 transfer.c:1037: 0 0

消失了

我新更新的 curl --version 数据

$卷曲-V

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.3 librtmp/2.3 协议：dict 文件 ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 功能：AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

于 2015-10-26T10:52:01.100 回答