This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rfk
Recipients docs@python, orsenthil, rfk
Date 2011-03-09.03:41:31
SpamBayes Score 7.847908e-10
Marked as misclassified No
Message-id <1299642093.48.0.578050525987.issue11448@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry, "endpoint" is just a noun that seemed to fit for me, I've no idea if there is a standard term for this.  Perhaps "origin server" if you follow the terminology from the RFC?

By way of example, suppose I'm running a proxy on localhost:3128 and I want to tunnel through it to connect to www.example.com:443.

From the train of thought that "I need to tunnel through localhost:3128 to connect to www.example.com:443" my instinct was to write code like this:

  c = HTTPSConnection("www.example.com",443)
  c.set_tunnel("localhost",3128)
  c.send('...etc...')

This doesn't work; it tries to tunnel through www.example.com to get to localhost.  The correct way around is:

  c = HTTPSConnection("localhost",3128)
  c.set_tunnel("www.example.com",443)
  c.send('...etc...')

Another way to put it:  the arguments to set_tunnel are the host/port to tunnel *to*, not the host/port to tunnel *through*.

I was only able to work this out by looking through to code for urllib2.  It's not clear from the docs.  Then again, sounds like my doc patch didn't make things any clearer :-)
History
Date User Action Args
2011-03-09 03:41:33rfksetrecipients: + rfk, orsenthil, docs@python
2011-03-09 03:41:33rfksetmessageid: <1299642093.48.0.578050525987.issue11448@psf.upfronthosting.co.za>
2011-03-09 03:41:31rfklinkissue11448 messages
2011-03-09 03:41:31rfkcreate