Bugs item #1346874, was opened at 2005-11-03 04:23
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib simply ignores CONTINUE
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-03 18:17
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
