2013-02-18 3 views
7

Ich benutze eine urllib.request.urlopen() zu GET von einem Web-Service, den ich versuche zu testen.Socket ResourceWarning mit Urllib in Python 3

Dies gibt ein HTTPResponse-Objekt zurück, das ich dann() gelesen habe, um den Antworttext zu erhalten.

Aber ich immer sehen, ist eine ResourceWarning über eine nicht geschlossene Buchse von socket.py

Hier wird die entsprechende Funktion:

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) 

Hier ist die Warnung, wie es in der Ausgabe des Programms erscheint:

$ ./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) 

Wenn es etwas gibt, was ich tun kann, um die HTTPResponse (oder die Anfrage?), Um es sauber zu machen, den Socket, würde ich wirklich gerne zu wissen, weil dieser Code für meine Komponententests ist; Ich mag es nicht Warnungen überall ignorieren, aber vor allem nicht dort.

+1

Ich kann es nicht auf Python 3.3.1 reproduzieren. Könntest du es mit der neuesten Python-Version testen? Es gab ein paar Fehler im Zusammenhang mit [Schließen des Sockets] (http://bugs.python.org/issue12133) (ResourceWarning bei Timeout) und ['" Verbindung: Schließen "' Antwortheader] (http: // bugs. python.org/issue12576) (zeigt an, dass es je nach Kopfzeile unterschiedliche Codepfade gibt). – jfs

Antwort

3

Ich weiß nicht, ob dies die Antwort ist, aber es ist Teil des Weges zu einer Antwort.

Wenn ich die Überschrift "connection: close" zu der Antwort von meinen Webdiensten hinzufügen, scheint das HTTPResponse-Objekt ohne Warnung richtig zu bereinigen.

Und in der Tat, die HTTP-Spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) sagt:

HTTP/1.1-Anwendungen, die in jeder Nachricht, die die "close" Verbindungsoption enthalten keine persistenten Verbindungen unterstützen muss.

So war das Problem auf dem Server-Ende (d. H. Mein Fehler!). Für den Fall, dass Sie keine Kontrolle über die Header haben, die vom Server kommen, weiß ich nicht, was Sie tun können.