[Python-Dev] Re: httplib

[Greg Stein]

On Mon, 5 Jun 2000, Jeremy Hylton wrote:
> >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
>...
>   >> Oh. Wait. Maybe that was it. You can't read the "next" response
>   >> until the first one has been read. Well... no need to block
>   >> putting new responses; we just need to create a way to "get the
>   >> next reply" and/or "can I get the next reply yet?"
> 
> Maybe I should clarify the concern I had here.  I think we're on the
> same page, but I'm not sure.
> 
> The problem with pipelined requests is that the client must be sure to
> read all of response I before it can call getreply to get response
> I+1.

Actually, you can issue a getreply() after you've read the prior
response's headers, but before you completely read its body. Once you have
the header, then you know whether the connection will remain open or not.
Assuming it *will* remain open, then you can go ahead and do a
request/reply sequence. If the connection is going to close, then you have
to fail at request time.

> I imagine that it could add a lot of complexity to use code to
> implement this requirement, e.g. when multiple threads are sharing a
> single connection.  It would be good if the library could do something
> reasonable about the multiplexing.  In the absence of making it just
> work, the library could raise an error that makes clear what has gone
> wrong -- that the client isn't using the interface properly.

I'm working through this stuff right now. It is a bit tricky to get it
right *and* have it clear. I'm concentrating on the latter as much as
possible.

At the moment, HTTPResponse instances can be created without problems. I'm
locating the "can you issue a request [and get a response]" logic in the
connection object itself.

Another detail that I'm trying to work through is where the connection is
allowed to get the HTTPResponse to read the HTTP header. Reading off the
network could block, so we need to be a bit more careful about what
methods can block (if any).

In any case, the current httplib (at www.lyra.org/greg/python/) has got
just about everything. The next checkin will deal with this pipelining
issue.


QUESTION #2: I *really* want to get rid of the HTTPS() class. It is
introducing excessive complexity, with the only purpose being
compatibility against the post-1.5.2 CVS.

Anyone? Thoughts on removal?


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/