urllib2.urlopen returns headers after content

[GoogleCodeExporter]

What steps will reproduce the problem?

I'm using the following unittest:

import unittest
import urllib2

import wsgi_intercept
from wsgi_intercept.test_wsgi_app import create_fn
from wsgi_intercept.urllib2_intercept import install_opener

class TestAutocomplete(unittest.TestCase):

    def setUp(self):
        install_opener()
        wsgi_intercept.add_wsgi_intercept('test_wsgi_intercept', 80, create_fn)

    def test_wsgi_intercept(self):
        print `urllib2.urlopen('http://test_wsgi_intercept/').read()`
        assert False  # Just so that nose doesn't hide the output.

if __name__ == '__main__':
    unittest.main()

What is the expected output? What do you see instead?

Per the documentation, I expect for it to print 'WSGI intercept
successful!\n'.  Instead, it shows 'WSGI intercept successful!\nHTTP/1.0
200 OK\nContent-type: text/plain\n\nWSGI intercept successful!\n'.

What version of the product are you using? On what operating system?

wsgi_intercept-0.3.1-py2.5.egg
Linux compakt 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686
GNU/Linux

Please provide any additional information below.

I can't figure out why it's tacking the headers onto the end of the
response.  If I look at the code for create_fn, it looks correct.

Thanks,
-jj

Original issue reported on code.google.com by jji...@gmail.com on 27 Dec 2007 at 7:52

[GoogleCodeExporter]

hmm, I can't seem to reproduce this.  I copied/pasted the code you sent and ran 
it
under 2.4 and 2.5 using nose 0.10.0.  Below is the output, which is not what you
reported.  Even if I remove the backticks, which would not force the read() 
value
into a string, then I still get the expected result.  Can you think of anything 
that
might be different on your system?

silo:~/tmp kumar$ nosetests wsgi_issue6.py 
F
======================================================================
FAIL: test_wsgi_intercept (wsgi_issue6.TestAutocomplete)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/kumar/tmp/wsgi_issue6.py", line 16, in test_wsgi_intercept
    assert False  # Just so that nose doesn't hide the output.
AssertionError: 
-------------------- >> begin captured stdout << ---------------------
'WSGI intercept successful!\n'

--------------------- >> end captured stdout << ----------------------

----------------------------------------------------------------------
Ran 1 test in 0.083s

FAILED (failures=1)

Original comment by kumar.mcmillan on 27 Dec 2007 at 8:10

[GoogleCodeExporter]

Are you running from trunk or from 0.3.1?

I'm slightly suspicious of the code in
wsgi_intercept-0.3.1-py2.5.egg/wsgi_intercept/__init__.py:makefile.

Thanks,
-jj

Original comment by jji...@gmail.com on 27 Dec 2007 at 8:14

[GoogleCodeExporter]

yeah, I installed the latest stable just to be sure.  I have
/opt/local/lib/python2.5/site-packages/wsgi_intercept-0.3.1-py2.5.egg/wsgi_inter
cept
... but I'm on mac instead of linux so I suppose there could be something 
different
there.  I don't have the __init__.py:makefile in that directory and yes this 
seems
very odd.

How exactly did you install it?  I assume easy_install wsgi_intercept.  If so, 
what
version of setuptools do you have?  I have 0.6c7

Original comment by kumar.mcmillan on 27 Dec 2007 at 8:33

[GoogleCodeExporter]

Yeah, I used easy_install wsgi_intercept.  I have setuptools-0.6c7-py2.5.egg.

When I say __init__.py:makefile, I'm referring to 
/usr/lib/python2.5/site-packages/wsgi_intercept-0.3.1-py2.5.egg/wsgi_intercept/_
_init__.py
right around line 418.

I put in a bunch of debugging code.  It would appear that makefile is getting 
called
twice, for some reason, and that self.output is not getting reset.  Hence, at 
the
end, self.output ends up with:

'HTTP/1.0 200 OK\nContent-type: text/plain\n\nWSGI intercept 
successful!\nHTTP/1.0
200 OK\nContent-type: text/plain\n\nWSGI intercept successful!\n'

Thanks,
-jj

Original comment by jji...@gmail.com on 27 Dec 2007 at 8:43

[GoogleCodeExporter]

*groan*

I found it.  Someone at my company in another part of the code was monkey 
patching
httplib.HTTPConnection.response_class.  Hence, sock.makefile was getting called
twice, somehow, as a result.

Sorry for wasting your time.

Original comment by jji...@gmail.com on 27 Dec 2007 at 8:59

[GoogleCodeExporter]

oh!  good, glad you found it.  It's no problem.  Actually, I wish wsgi_intercept
didn't have to monkey patch things so much -- I have a sinking feeling it is 
going to
bite really hard one day.  The urllib stuff is pretty clean though because it 
just
registers handlers.  Thanks for taking the time to report the issue.

Original comment by kumar.mcmillan on 27 Dec 2007 at 9:02

• Changed state: Invalid