在 Python 3 中使用 urllib 的套接字资源警告答案

【问题标题】：socket ResourceWarning using urllib in Python 3在 Python 3 中使用 urllib 的套接字资源警告
【发布时间】：2013-02-18 14:35:07
【问题描述】：

我正在使用 urllib.request.urlopen() 从我正在尝试测试的 Web 服务获取。

这会返回一个 HTTPResponse 对象，然后我通过 read() 来获取响应正文。

但我总是从 socket.py 中看到关于未关闭套接字的 ResourceWarning

下面是相关函数：

from urllib.request import Request, urlopen

def get_from_webservice(url):
    """ GET from the webservice  """
    req = Request(url, method="GET", headers=HEADERS)
    with urlopen(req) as rsp:
        body = rsp.read().decode('utf-8')
        return json.loads(body)

这是程序输出中出现的警告：

$ ./test/test_webservices.py
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py:359: ResourceWarning: unclosed <socket.socket object, fd=5, family=30, type=1, proto=6>
self._sock = None
.s
----------------------------------------------------------------------
Ran 2 tests in 0.010s

OK (skipped=1)

如果我可以对 HTTPResponse（或请求？）做任何事情以使其干净地关闭其套接字，我真的很想知道，因为这段代码是用于我的单元测试的；我不喜欢忽略任何地方的警告，尤其是不在那儿。

【问题讨论】：

我无法在 Python 3.3.1 上重现它。你能在最新的 Python 版本上测试它吗？有几个与closing the socket（超时时的资源警告）和"Connection: close" response header（根据标头显示不同的代码路径）相关的错误。

标签： python python-3.x warnings urllib

【解决方案1】：

我不知道这是否是的答案，但它是答案的一部分。

如果我将标题“connection: close”添加到来自我的 Web 服务的响应中，HTTPResponse 对象似乎会在没有警告的情况下正确清理自己。

事实上，HTTP 规范 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) 说：

不支持持久连接的 HTTP/1.1 应用程序必须在每条消息中包含“关闭”连接选项。

所以问题出在服务器端（即我的错！）。如果您无法控制来自服务器的标头，我不知道您能做什么。

【讨论】：

【解决方案2】：

urllib3 也有同样的问题，我只是添加了一个上下文管理器来自动关闭连接：

import urllib3

def get(addr, headers):
    """ this function will close the connection after a http request. """
    with urllib3.PoolManager() as conn:
        res = conn.request('GET', addr, headers=headers)
        if r.status == 200:
            return res.data
        else:
            raise ConnectionError(res.reason)

请注意，urllib3 旨在拥有一个连接池并为您保持连接处于活动状态。如果它需要发出一系列请求，这可以显着加快您的应用程序，例如很少调用后端 API。

请在此处阅读urllib3 重新连接池的文档：https://urllib3.readthedocs.io/en/1.5/pools.html

P.S.您也可以使用 requests lib，它不是 Python 标准库的一部分（2019 年），但非常强大且易于使用： http://docs.python-requests.org/en/master/

【讨论】：