Logged In: YES 
user_id=6501

Eek. Following this model, then when we want to add Basic
authentication support, then we'll have the following classes:

  HTTPBasicConnection
  HTTPSBasicConnection
  HTTPBasicProxyConnection
  HTTPSBasicProxyConnection

Oh, and what if we want Digest support? Another set of four?
But what if we want the connection to support *both* Basic
or Digest, depending upon how the server was configured?
Let's not forget the client certificates. Oh, and layering
DAV capability on this.

The point is: adding features by adding classes will produce
a combinatoric nightmare. While I certainly agree with the
idea of pushing proxy support "down" from urllib(2) into the
basic http classes, I'd rather see a design that doesn't
require a new class for every feature combination.

PEP 268 was the start of an attempt to rationalize the
various features around HTTP. Some of the basic feature sets
to support:

* SSL
* various forms of authentication (Basic, Digest, client
cert, ...)
* WebDAV
* Proxy
* Proxy auth

I'd much rather see proxy features folded right into the
connection classes, than to spawn new ones. Even better, I'd
suggest picking up PEP 268 and modifying it where "you"
(whoever might read this comment) disagree or have further
design ideas.

(IOW, count me a -1 to the approach suggested by this patch)