I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None

Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.

Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?

Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

Logged In: YES 
user_id=67930

I did submit a patch for this, not sure if you noticed. I've
been using it for quite a while and it seems to be working
flawlessly, granted I'm always pretty much using it in the
same context.

Logged In: NO 

I've got a patch for this bug.  How do I submit it?

Logged In: YES 
user_id=67930

I've already submitted a patch for this:

http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Just waiting for it to be accepted.

Logged In: YES 
user_id=31392

Fix in httplib.py rev. 1.52.