I would like to propose a few changes to the (new) httplib: *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to provide backwards-compat for it *) revamp the pipeline support: - record the "last response object" ... when a new getreply() is done, then we store the "last" into response.prior - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and performed by the response object - the read of that line is lazy - if the response line is read *before* the "prior" response (if any) is "closed", then an exception is raised: ResponseNotReady *) address some of Moshe's concerns: - use class-based exceptions - clarify that HTTPConnection is designed for *blocking* sockets - conn.close() followed by conn.send() will reopen the socket. This could lead to programming errors. I'll add a class-based default flag to disable this behavior. - in request(), we check for errno==32 ... what to do on Windows? I will implement these changes in small chunks so that each can be reviewed in my CVS repository. The history is available at: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ Cheers, -g -- Greg Stein, http://www.lyra.org/
All of the work below has been completed except for the errno==32 stuff. Module: http://www.lyra.org/greg/python/httplib.py History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ There are three items left, that I know of: 1) need doc for new stuff 2) need new test cases 3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, <malformed line>, None) and store <file ob hooked to socket> into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file Thoughts? Comments? I'd like to get this thing into Python RSN. Cheers, -g On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote:
I would like to propose a few changes to the (new) httplib:
*) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to provide backwards-compat for it
*) revamp the pipeline support:
- record the "last response object" ... when a new getreply() is done, then we store the "last" into response.prior - reading of the "HTTP/1.1 <code> <msg>" line is deferred, and performed by the response object - the read of that line is lazy - if the response line is read *before* the "prior" response (if any) is "closed", then an exception is raised: ResponseNotReady
*) address some of Moshe's concerns:
- use class-based exceptions - clarify that HTTPConnection is designed for *blocking* sockets - conn.close() followed by conn.send() will reopen the socket. This could lead to programming errors. I'll add a class-based default flag to disable this behavior. - in request(), we check for errno==32 ... what to do on Windows?
I will implement these changes in small chunks so that each can be reviewed in my CVS repository. The history is available at:
-- Greg Stein, http://www.lyra.org/
On Sun, 11 Jun 2000, Greg Stein wrote:
3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, <malformed line>, None) and store <file ob hooked to socket> into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file
What do the old docs say about this? \begin{methoddesc}{getfile}{} Return a file object from which the data returned by the server can be read, using the \method{read()}, \method{readline()} or \method{readlines()} methods. \end{methoddesc} So why not put a "dummy" file: one whose read(), readline() or readlines() act as if it was at EOF? (IOW, the Pythonic equivalent of open("/dev/null")) -- Moshe Zadka <moshez@math.huji.ac.il> http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote:
On Sun, 11 Jun 2000, Greg Stein wrote:
3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, <malformed line>, None) and store <file ob hooked to socket> into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file
What do the old docs say about this?
\begin{methoddesc}{getfile}{} Return a file object from which the data returned by the server can be read, using the \method{read()}, \method{readline()} or \method{readlines()} methods. \end{methoddesc}
So why not put a "dummy" file: one whose read(), readline() or readlines() act as if it was at EOF? (IOW, the Pythonic equivalent of open("/dev/null"))
Sure, I can put different things there, but that would also be a change in semantics. The backwards compat class, HTTP, preserves the API completely -- even down to how it reacts in error situations. (although, it *can* raise errors that it didn't before, when you use methods in the wrong order) I'd like to make a change in the semantics for this particular error condition. Where a client used to be able to do: errcode, errmsg, hdrs = h.getreply() if errcode == -1: file = h.getfile() print 'ERROR: some kind of error occurred' print ' partial read:', `errmsg` print ' next 100 bytes:', `file.read(100)` I'd like to eliminate that "next 100 bytes" ability, and just close the socket when a protocol error occurs. Before making a change in behavior for this (central) class, I'd like to get some feedback. Some voting? Cheers, -g -- Greg Stein, http://www.lyra.org/
participants (2)
-
Greg Stein -
Moshe Zadka