httplib strict mode fails in 2.2.2

[jhylton]

BPO	527521
Nosy	@akuchling

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-01-31.14:14:40.000>
created_at = <Date 2002-03-08.19:57:03.000>
labels = ['extension-modules']
title = 'httplib strict mode fails in 2.2.2'
updated_at = <Date 2003-01-31.14:14:40.000>
user = 'https://bugs.python.org/jhylton'

bugs.python.org fields:

activity = <Date 2003-01-31.14:14:40.000>
actor = 'jhylton'
assignee = 'jhylton'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2002-03-08.19:57:03.000>
creator = 'jhylton'
dependencies = []
files = []
hgrepos = []
issue_num = 527521
keywords = []
message_count = 6.0
messages = ['9582', '9583', '9584', '9585', '9586', '9587']
nosy_count = 4.0
nosy_names = ['jhylton', 'akuchling', 'nnorwitz', 'mbrierst']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue527521'
versions = []

[jhylton]

The test() function in the httplib module attempts to
connect to SourceForge using SSL. I've tried this
with Python 2.1 and up, using OpenSSL 0.9.6. The read
call fails with an SSL error, then python dumps core
instead OpenSSL.

I don't know if this is a Python bug or an SSL bug.
At first blush, I'd guess that Python is probably
using OpenSSL incorrectly.

Here's the Python traceback.

Traceback (most recent call last):
  File "../Lib/httplib.py", line 895, in ?
    test()
  File "../Lib/httplib.py", line 884, in test
    status, reason, headers = hs.getreply()
  File "../Lib/httplib.py", line 734, in getreply
    response = self._conn.getresponse()
  File "../Lib/httplib.py", line 579, in getresponse
    response = self.response_class(self.sock)
  File "../Lib/httplib.py", line 99, in __init__
    self.fp = sock.makefile('rb', 0)
  File "../Lib/httplib.py", line 614, in makefile
    buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version number')

And the gdb stack trace.

#0 0x401e96d1 in sk_pop_free ()
from /usr/local/ssl/lib/libcrypto.so.0.9.6
(gdb) bt
#0 0x401e96d1 in sk_pop_free ()
from /usr/local/ssl/lib/libcrypto.so.0.9.6
#1 0x40191068 in __DTOR_END__ ()
from /usr/local/ssl/lib/libssl.so.0.9.6
#2 0xe853 in ?? ()
Cannot access memory at address 0x5614ec83.

[akuchling]

Logged In: YES
user_id=11375

This looks like a duplicate of bug bpo-531616, though I
didn't see Python dump core. Try it with the current
httplib in CVS; it should be fixed.

[nnorwitz]

Logged In: YES
user_id=33168

Jeremy, can this bug be closed? www.python.org is down. I
tried sf.net and there was no crash. But I did get this
exception: XXX strict mode should have failed

I'm not sure if that's a problem or not.

[jhylton]

Logged In: YES
user_id=31392

I don't see the coredump either; the C code is very
different in 2.1, so it's probably a 2.1-specific bug. But
the XXX strict mode problem in 2.2 is probably a bug.

[mbrierst]

Logged In: YES
user_id=670441

This actually does its tests by communicating with various web servers (python.org, sourceforge, theopalgroup.com, yahoo.com). This doesn't seem like a very reliable way to do these tests, but it certainly does seem like a 'real-world' test.

Apparently yahoo.com/promotions/mom_com97/supermom.html used to give a garbled, non-standard status line, so it was used to give an error case to strict mode. Unsurprisingly this page has gone away and the new Not Found error page is standards compliant.

You can either

1. get rid of the tests of the buggy server entirely (all code starting where it mentions yahoo)
2. someone can create a server which ALWAYS gives a garbled status line (maybe on python.org?) but this seems like it's not worth the effort, and there's still no guarantee that server won't go away in the future.
3. Create a mini-server in the test just to spit out a bad status line and make this test work.
4. get rid of these tests all together, as it seems unreliable to rely on external servers for them

Option 1) is the least work and probably the best idea. If you want a patch for 1), 3), or 4) I can provide it, or someone else can do it if they want.

[jhylton]

Logged In: YES
user_id=31392

The test using supermom was removed on the trunk. I also
removed it on the 2.2 maintenance branch. I think we can
close this bug now.