[Jython-bugs] [ jython-Bugs-1751963 ] bug on httplib.HTTPConnection

[SourceForge.net <no...@so...>]

Bugs item #1751963, was opened at 2007-07-11 15:01
Message generated for change (Comment added) made by amak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1751963&group_id=12867

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andre M. Descombes (amdescombes)
Assigned to: Alan Kennedy (amak)
Summary: bug on httplib.HTTPConnection

Initial Comment:
Hello,

httplib.HTTPConnection looses the connection after each request call.

Regards,

Andre M. Descombes

----------------------------------------------------------------------

>Comment By: Alan Kennedy (amak)
Date: 2007-07-15 19:49

Message:
Logged In: YES 
user_id=647684
Originator: NO

The second part of this bug was related to exceptions.

The error handling in httplib is essentially cpython specific. For
example, when the connection to the server had been closed, it would be
detected with a try .. except, catching socket.error. But the error number
had to be the error number that cpython creates in this circumstance. This
is the relevant code from httplib.

try:
    self.sock.sendall(str)
except socket.error, v:
    if v[0] == 32:      # Broken pipe
        self.close()
    raise

As you can see, it is expecting that

A: The exception object is a tuple
B: That the first item in that tuple is the integer 32, which is the error
number of "Broken Pipe".

I have now mapped the underlying java exception so that it maps to the
same error number as cpython, so the above code will actually work on
jython now.

It is also important to note that the httplib shipped with jython 2.1
broke in the circumstances described in this bug, i.e. this bug has always
existed on jython before now. On jython 2.1, the sequence went like this

1. The first read would complete, the FileWrapper would be closed, thus
causing the underlying socket to also be closed.
2. The auto_open flag was true on httplib.HTTPConnection
3. Which meant that httplib would attempt to send on the socket anyway,
hoping to catch the exception if anything went wrong.
4. But the error handling, described above, expected exceptions to (int,
string) tuples, not java exceptions, so attempting to get the error number
failed, as you can see from this transcript of running the httplib example
on jython 2.1

C:\httplibBug>jython21 closesConnectionBug.py
200 OK
Traceback (innermost last):
  File "closesConnectionBug.py", line 7, in ?
  File "C:\jython21\Lib\httplib.py", line 508, in request
  File "C:\jython21\Lib\httplib.py", line 517, in _send_reques
  File "C:\jython21\Lib\httplib.py", line 437, in putrequest
  File "C:\jython21\Lib\httplib.py", line 393, in send
AttributeError: __getitem__
C:\httplibBug>

So, in summary, yes this was a bug, but it's a bug that's been in jython
forever, and only now is it possible to solve the bug.

----------------------------------------------------------------------

Comment By: Alan Kennedy (amak)
Date: 2007-07-15 19:37

Message:
Logged In: YES 
user_id=647684
Originator: NO

The first jython socket bug relating to this problem involves the use of
socket FileWrappers.

When httplib creates an HTTPResponse object, which handles the response,
it uses socket.makefile to wrap socket, and then closes that file wrapper
when finished. Note that this does NOT close the underlying socket, just
the wrapper around it.

In the old jython socket module, when a FileWrapper was closed, it closed
the socket as well. This is wrong behaviour, but it's been there since the
beginning.

The new socket module was a rewrite of the old module, but some behaviours
were carried forward, and closing the socket underlying the FileWrapper was
one of them.

I have now corrected the behaviour, i.e. closing a socket FileWrapper no
longer closes the underlying socket.

It is worth noting that the code sample given above never ran on jython
before now; this is the first time it has ever run successfully. More on
this in the next message.


----------------------------------------------------------------------

Comment By: Alan Kennedy (amak)
Date: 2007-07-15 19:29

Message:
Logged In: YES 
user_id=647684
Originator: NO

The following example code, taken from the cpython httplib documentation,
illustrates this bug

# -=-=-=
import httplib
conn = httplib.HTTPConnection("www.python.org")
conn.request("GET", "/index.html")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.request("GET", "/parrot.spam")
r2 = conn.getresponse()
print r2.status, r2.reason
data2 = r2.read()
conn.close()
# -=-=-=

Which gives the following behaviour on cpython 2.4

C:\httplibBug>python closesConnectionBug.py
200 OK
404 Not Found

And the following behaviour on jython 2.2rc

C:\httplibBug>jython22 closesConnectionBug.py
200 OK

Traceback (innermost last):
  File "closesConnectionBug.py", line 7, in ?
  File "C:\jython_trunk\jython\dist\Lib\httplib.py", line 705, in request
  File "C:\jython_trunk\jython\dist\Lib\httplib.py", line 728, in
_send_request
  File "C:\jython_trunk\jython\dist\Lib\httplib.py", line 699, in
endheaders
  File "C:\jython_trunk\jython\dist\Lib\httplib.py", line 585, in
_send_output
  File "C:\jython_trunk\jython\dist\Lib\httplib.py", line 564, in send
  File "C:\jython_trunk\jython\dist\Lib\socket.py", line 511, in send
error: (-1, 'Unmapped java exception:
<java.nio.channels.ClosedChannelException:None>')

The cause of this is actually two separate bugs, which I will discuss in a
separate message.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1751963&group_id=12867