[Python-Dev] more on httplib

[Greg Stein]

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/