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/