HTTP Authentication

Thehttpx module will provide a mixin for performing HTTPauthentication (for both proxy and origin server authentication). Thismixin (httpx.HandleAuthentication) can be combined with theHTTPConnection and theHTTPSConnection classes (the mixin maypossibly work with the HTTP and HTTPS compatibility classes, but thatis not a requirement).

The mixin will delegate the authentication process to one or more“authenticator” objects, allowing multiple connections to shareauthenticators. The use of a separate object allows for a long termconnection to an authentication system (e.g. LDAP). An authenticatorfor the Basic and Digest mechanisms (seeRFC 2617) will beprovided. User-supplied authenticator subclasses can be registered andused by the connections.

A “credentials” object (httpx.Credentials) is also associated withthe mixin, and stores the credentials (e.g. username and password)needed by the authenticators. Subclasses of Credentials can be createdto hold additional information (e.g. NT domain).

The mixin overrides thegetresponse() method to detect401(Unauthorized) and407(ProxyAuthenticationRequired)responses. When this is found, the response object, the connection,and the credentials are passed to the authenticator corresponding withthe authentication scheme specified in the response (multipleauthenticators are tried in decreasing order of security if multipleschemes are in the response). Each authenticator can examine theresponse headers and decide whether and how to resend the request withthe correct authentication headers. If no authenticator cansuccessfully handle the authentication, then an exception is raised.

Resending a request, with the appropriate credentials, is one of themore difficult portions of the authentication system. The difficultyarises in recording what was sent originally: the request line, theheaders, and the body. By overriding putrequest, putheader, andendheaders, we can capture all but the body. Once the endheadersmethod is called, then we capture all calls to send() (until the nextputrequest method call) to hold the body content. The mixin will havea configurable limit for the amount of data to hold in this fashion(e.g. only hold up to 100k of body content). Assuming that the entirebody has been stored, then we can resend the request with theappropriate authentication information.

If the body is too large to be stored, then thegetresponse()simply returns the response object, indicating the 401 or 407error. Since the authentication information has been computed andcached (into the Credentials object; see below), the caller can simplyregenerate the request. The mixin will attach the appropriatecredentials.

A “protection space” (seeRFC 2617, section 1.2) is defined as a tupleof the host, port, and authentication realm. When a request isinitially sent to an HTTP server, we do not know the authenticationrealm (the realm is only returned when authentication fails). However,we do have the path from the URL, and that can be useful indetermining the credentials to send to the server. The Basicauthentication scheme is typically set up hierarchically: thecredentials for/path can be tried for/path/subpath. TheDigest authentication scheme has explicit support for the hierarchicalsetup. Thehttpx.Credentials object will store credentials formultiple protection spaces, and can be looked up in two differentways:

1. looked up using(host,port,path) – this lookup scheme isused when generating a request for a path where we don’t know theauthentication realm.
2. looked up using(host,port,realm) – this mechanism is usedduring the authentication process when the server has specified thatthe Request-URI resides within a specific realm.

TheHandleAuthentication mixin will overrideputrequest() toautomatically insert credentials, if available. The URL from theputrequest is used to determine the appropriate authenticationinformation to use.

It is also important to note that two sets of credentials are used,and stored by the mixin. One set for any proxy that may be used, andone used for the target origin server. Since proxies do not havepaths, the protection spaces in the proxy credentials will always use“/” for storing and looking up via a path.

Proxy Handling

Thehttpx module will provide a mixin for using a proxy to performHTTP(S) operations. This mixin (httpx.UseProxy) can be combinedwith theHTTPConnection and theHTTPSConnection classes (themixin may possibly work with the HTTP and HTTPS compatibility classes,but that is not a requirement).

The mixin will record the(host,port) of the proxy to use. XXXwill be overridden to use this host/port combination for connectionsand to rewrite request URLs into the absoluteURIs referring to theorigin server (these URIs are passed to the proxy server).

Proxy authentication is handled by thehttpx.HandleAuthenticationclass since a user may directly useHTTP(S)Connection to speakwith proxies.

WebDAV Features

Thedavlib module will provide a mixin for sending WebDAV requeststo a WebDAV-enabled server. This mixin (davlib.DAVClient) can becombined with theHTTPConnection and theHTTPSConnectionclasses (the mixin may possibly work with the HTTP and HTTPScompatibility classes, but that is not a requirement).

The mixin provides methods to perform the various HTTP methods definedby HTTP inRFC 2616, and by WebDAV inRFC 2518.

A custom response object is used to decode207(Multi-Status)responses. The response object will use the standard library’s xmlpackage to parse the multistatus XML information, producing a simplestructure of objects to hold the multistatus data. Multiple parsingschemes will be tried/used, in order of decreasing speed.