I bumped into this code in httplib.py HTTPConnection,
begin():

        # read until we get a non-100 response
        while True:
            version, status, reason = self._read_status()
            if status != CONTINUE:
                break
            # skip the header from the 100 response
            while True:
                skip = self.fp.readline().strip()
                if not skip:
                    break
                if self.debuglevel > 0:
                    print "header:", skip

This basically silently eats any 100-continue response
that the server may send to us.
This is not according to the spec - the client should
WAIT for the 100-continue, and then post the data.
Because of this code snippet, it is impossible for a
client to wait for a 100-continue response, since it is
silently eaten by this code.

A correct implementation would be:

- Check the outgoing headers for "Expect: 100-continue"
- If that is present, set an "expectcontinue" flag.
- If the client tries to send data to the connection,
or if the data member was set in the request, wait for
the server to send the 100 response BEFORE sending out
any data at all, if the flag is set.
- If the server fails to send it, the connection will
eventually time out.

I'd be happy to provide an implementation myself, as it
doesn't seem hard to implement and would really help my
project.

Logged In: YES 
user_id=33168

It's much easier to get a patch integrated since there
should be less work than a bug.  I encourage you to work on
a patch.  

Don't forget that a patch, must do many things:  1) fix the
code, 2) fix (or add!) tests, 3) fix the documentation with
an appropriate \versionchanged (or \versionadded) tag, and
finally 4) update Misc/NEWS.

The old behaviour should generally be backwards compatible
by default when adding new functionality.  If it's a bug, it
may still be desirable to maintain backwards compatibility.
 I don't know enough about HTTP to provide any guidance here.

Logged In: YES 
user_id=261020

I don't see any violation of RFC 2616 here.  Which part of
the spec., precisely, do you claim is violated?

Still, implementing better 100 Continue handling would be
useful, if done correctly, so go ahead and write that patch!

I'm implemented the behavior described by Mike above with a patch to
2.6. The patch will raise an ExpectationFailed before sending the body
if the server responds with a 417 (Expectation Failed).

This patch should only modify behavior for requests that specify
"Expect: 100-continue" in the request's headers.

Note: The spec says that the client should send the body if the server
does not respond within some reasonable period of time. This is not
currently supported. Anyone have any thoughts on how that could be done?

I have run into this same issue. It does violate RFC2616 in section 4.3 "All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length."

The embedded while loop is looking for entity data coming back from the server which will never be seen. In my tests the code dies with an exception. I don't see why anything is being done special for a 100 CONTINUE at all. My fix was to eliminate the code previously quoted and replace it with a single line of code so that it would now look like the code snippet below.

   def begin(self):
        if self.msg is not None:
            # we've already started reading the response
            return
        version, status, reason = self._read_status()
        self.status = status
        self.reason = reason.strip()

Note on providing a patch as stated previously.

Having this restriction on providing a patch is a large deterrent to people. I spent a lot of time myself finding the cause of the issues I was having. I don't really have the time to fix tests and documentation also. I understand the reason for asking, but it certainly is a discouragement to helping when bugs are found.

Carl, anyone is free to submit an incomplete patch, and people often do, but if people who are affected by an issue do not think it worth their time to complete it, or even move it along, there is no reason to expect people who are not affected by it to think so either. All of us volunteers are busy doing whatever it is we do.