client-side [was: Re: [Web-SIG] Random thoughts]

[John J Lee]

On Fri, 31 Oct 2003, Greg Stein wrote:

> On Fri, Oct 31, 2003 at 04:34:02PM +0000, John J Lee wrote:
[...]
> > He was talking about the server side!
>
> No, Greg Ward was talking about an http client. Otherwise, he would not
> have mentioned PEP 268.

OK.  Personally, I don't think the client-side stuff particularly well
bundled in with the server-side stuff, but I guess I'm not really
bothered.  I don't think any of the stuff we've discussed so far is
particularly helpfully described as "an http client", though.

[...]
> > >   * SSL
> >
> > That's already down at the httplib level (and the socket level, of
> > course).
>
> I know that (given that I wrote the current httplib :-). However, I
> maintain that the implementation uses an improper design.

Fine.


> > >   * Basic/Digest/??? authentication
> >
> > That's naturally done at the urllib / urllib2 level, given the way it
> > works.
>
> There is nothing "natural" about it. That is where it resides, but
> authentication is part of the HTTP specification and should be able to be
> used by anything attempting to interact at the HTTP level. HTTP is far

OK.


> more than "fetch the contents of this URL."

Yes.  And simultaneously far less, depending on how you look at it...

[note to self: stop getting philosophical in Python threads]


> My list was specifically intended to say: each of these items belongs in
> the core HTTP (client) service layer. Not urllib.

Indeed.  That's why I was commenting on that question.

[...]
> > > The current model for the client side uses two, distinct classes to deal
> > > with the SSL feature.
> >
> > Sorry, which classes are they?
>
> HTTPConnection and HTTPSConnection.  (or HTTP and HTTPS for the backwards
> compat stuff). See above about combinatorics using this design model.

<shrug> if it causes problems for somebody (at the httplib / httpx level),
I guess it should be fixed.


> > > I have an entirely separate module for the WebDAV stuff.
> >
> > How should it be integrated (if at all), in your opinion (assuming you
> > want it in the standard library)?
>
> See PEP 268.
[...]

OK, I see it won't be part of httplib, but a separate module httpx.  As
long as you can send one HTTP request, and get back one HTTP response, and
know that httplib isn't going to "swallow" any HTTP responses, no problem.
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?  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.

Where is this proxy / auth code?  davlib?


John