HTTPS intercept defaults to port 80

[GoogleCodeExporter]

What steps will reproduce the problem?
1. wsgi_intercept.add_wsgi_intercept('nonexistent-domain.com', 80, 
first_wsgi_app)
2. wsgi_intercept.add_wsgi_intercept('nonexistent-domain.com', 443, 
second_wsgi_app)
3. wsgi_intercept.urllib2_intercept.install_opener()
4. urllib2.urlopen('https://nonexistent-domain.com')

What is the expected output? What do you see instead?
This should trigger the "second_wsgi_app" intercept. Instead, it triggers the 
"first_wsgi_app" intercept.

What version of the product are you using? On what operating system?
I am using wsgi_intercept from SVN r50 trunk. This occurs on both Windows 7 and 
Ubuntu 10.04.

Please provide any additional information below.
I am attaching a patch that fixes this for urllib2 by creating a 
WSGI_HTTPSConnection class. It fixes the test case for HTTPS and adds a new 
test to ensure that the default port for HTTP remains 80. It also includes the 
patch from Issue 10. I did not modify the other interceptors.

Original issue reported on code.google.com by p4pe...@gmail.com on 19 May 2011 at 10:16

Attachments:

• https.patch

[GoogleCodeExporter]

thanks for the patch

Original comment by kumar.mcmillan on 19 May 2011 at 10:46

• Added labels: Type-Patch

[GoogleCodeExporter]

This is a revised patch that fixes httplib_intercept as well as 
urllib2_intercept. The commit message for r50 mentioned that the tests for 
httplib_intercept were failing so I fixed them so that they now pass. HTTPS in 
both urllib2 and httplib now default to port 443 instead of 80.

I left the directory structure alone, but you might want to revisit why most of 
the interceptors are in a subdirectory (like urllib2_intercept/__init__.py) 
rather than just a file (like httplib_intercept.py). I think webunit_intercept 
is the only one that actually needs its own directory. That, however, probably 
belongs in a separate issue.

Original comment by p4pe...@gmail.com on 20 May 2011 at 6:25

Attachments:

• https.v2.patch

[GoogleCodeExporter]

thanks!  I committed this all to revision 52 and attributed the patch to Eion 
Robb (that's you, right?).  I also upgraded the project to use tox for tests.  
The tests are mostly passing in 2.5 but newer versions of Python have failures. 
 Here is my output http://pastebin.mozilla.org/1231745 (not sure what that 
zope.testbrowser failure is about).  You can see more failures with tox -e 
py26,py27

Original comment by kumar.mcmillan on 21 May 2011 at 7:40

• Changed state: Fixed

[GoogleCodeExporter]

Oh, I didn't realize I hadn't signed anything. My name is actually Peter 
Henderson. Sorry about that, and thanks for committing this all so quickly!

I've never used zope.testbrowser and I don't have it set up to verify this, but 
it looks like the failure is because the test adds the intercept on port 80 but 
makes a request on port 443. Since my change makes HTTPS properly default to 
port 443, the test should be updated to add the intercept on port 443 (copy the 
@with_setup line from the test below). I think the body of the test should 
remain the same to test that an HTTPS request without a port defaults to port 
443.

Original comment by p4pe...@gmail.com on 21 May 2011 at 8:01

[GoogleCodeExporter]

Ah, whoops, Google Code profiles are prohibitively anonymous for these kinds of 
things :) I fixed the name in authors.

Yep, changing the intercept fixed that tests.  So everything passes in 2.5 and 
the only failures in 2.6 seem to be related to missing gopher support, heh

Original comment by kumar.mcmillan on 21 May 2011 at 8:10