Changes by Martin Panter vadmium...@gmail.com:
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1348
___
___
Python-bugs-list
Changes by A.M. Kuchling li...@amk.ca:
--
resolution: - invalid
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1348
___
Mark Lawrence breamore...@yahoo.co.uk added the comment:
No reply to msg114602 so I'll close in a couple of weeks unless anyone objects.
--
nosy: +BreamoreBoy
status: open - pending
___
Python tracker rep...@bugs.python.org
Georg Brandl ge...@python.org added the comment:
Is this still relevant?
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1348
___
Changes by Jeremy Hylton [EMAIL PROTECTED]:
--
nosy: +jhylton
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
___
Python-bugs-list mailing list
Unsubscribe:
vila added the comment:
Well I was confused.
In fact, I have a working http/1.1 client which indeed works around that
close.
HTTPConnection.close() must be called once the response has been
processed or the next request can't be handled since
HTTPConnection.__state is not _CS_IDLE.
Bill Janssen added the comment:
That's because the socket.py code has been adapted (the first word I wrote
there was perverted :--) to deal with this case. That is, the close() has
been rendered meaningless because of the explicit reference counting in
socket.py. But the right solution is to
Bill Janssen added the comment:
No, the close must be removed. It's the wrong *way* to transfer
responsibility. Close means close, not I wash my hands of
responsibility here. What's hidden here is that the open socket is
transferred to the response, which continues to use it. In fact, the
Guido van Rossum added the comment:
Bill, is there a code example that should work but breaks because of
that close()? ATM, there doesn't seem to be anything in the tests that
breaks...
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
vila added the comment:
The title of this bug is scary.
httplib rightly close the socket because that's the way to transfer the
responsibility of the close to the user of the HttpResponse object.
The close MUST stays there.
I do encounter a bug related to that close while trying to use the
Guido van Rossum added the comment:
Is this still relevant?
--
assignee: - janssen
priority: urgent - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
___
Bill Janssen added the comment:
Yes. The close is stil in the wrong place.
On Nov 21, 2007 2:30 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Is this still relevant?
--
assignee: - janssen
priority: urgent - normal
Guido van Rossum added the comment:
I don't think that patch is the right thing either. Certainly the
comment on the line you're proposing to delete is suggesting that the
close() call was added for a reason.
--
nosy: +gvanrossum
__
Tracker [EMAIL
Bill Janssen added the comment:
I still think the semantics are wrong here, but someone needs to close
this connection at some point, and right now the reference-counting
semantics of socket.close() are the only thing preventing a leak. So I
think my patch should not be applied. Instead, a
New submission from Bill Janssen:
I can't get urllib.urlopen() to work with SSL, and it seems to be due to
a bug in the re-write of httplib. HTTPConnection.getresponse() is
closing the socket, but then returning a response object holding onto
that closed socket to the caller, who then tries
Bill Janssen added the comment:
I believe this is all that's needed.
Added file: http://bugs.python.org/file8638/c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
c
Description: Binary data
17 matches
Mail list logo
