[Web-SIG] Re: client-side http

[John J Lee]

On Sat, 1 Nov 2003, Greg Stein wrote:
> On Sat, Nov 01, 2003 at 12:50:25PM +0000, John J Lee wrote:
[...]
> That said, the http code *could* automatically resend a request with new
> credentials. It already attempts to resend when it sees a broken pipe (the
> server closed its connection; usually from a timeout).

Yeah, but that does seem much more transport-y and low-level than
authentication and proxying.


> > But I see your PEP doesn't break that simple way of working (in fact I
> > don't know why I was worried about that in the first place...).  Is there
> > any reason not to arrange your stuff in such a a way as to allow
> > reimplementing a maximal part of urllib2's proxy / auth handlers in terms
> > of your code?
>
> The hope was to refactor all the authentication, proxy handling, and
> proxy-auth handling down into "httpx" ("httplib extensions"). And then,
> yes, urllib(2) would be reimplemented in terms of httpx.

Well, the choice I was discussing was that between reimplementing the
stuff like urllib2.HTTPBasicAuthHandler using httpx (which I guess would
require some refactoring of httpx), OR just reimplementing
urllib2.AbstractHTTPHandler using httpx (ie. replacing HTTP / HTTPS with
whatever class(es) from httplib / httpx).  You're suggesting the latter,
obviously.  There's no equivalent issue for urllib, I guess.


> > But perhaps I'm too concerned about the simplicity of the
> > non-swallowing nature of the current httplib, in these particular cases of
> > authentication and proxying -- maybe in practice that can be given up
> > without ill-effects (not by changing httplib, but by deprecating the
> > auth/proxy code in urllib2 (and urllib too I guess)).  Not sure.
>
> Yup. I wanted to leave httplib alone, or with just minimal changes, and
> then to layer on new HTTP handling code via httpx. By refactoring that
> stuff out of urllib, then it could be used for any HTTP code. For example,
> if you wanted to write some GUI that interacted with a server via WebDAV,
> then you'd be able to use cool auth, proxies, etc for those interactions.
[...]


John