[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue1491] BaseHTTPServer incorrectly implements response code 100

Senthil Kumaran added the comment: Fixed and committed in revision 85125. Actually, this changes the behavior of BaseHTTPServer a little and adds two new methods to the code, so I don't think, this should be back-ported to 2.7 and 3.1. If older code were to encounter the new 100 Continue resp

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Senthil Kumaran : -- assignee: -> orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Mark Lawrence : -- stage: -> patch review versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker ___

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Mark Lawrence : Removed file: http://bugs.python.org/file10684/BaseHTTPServer_continue_2.patch ___ Python tracker ___ ___ Python-bug

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Mark Lawrence : Removed file: http://bugs.python.org/file10278/BaseHTTPRequestHandlerTestCase.py ___ Python tracker ___ ___ Python-b

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Mark Lawrence : Removed file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch ___ Python tracker ___ ___ Python-bugs-

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Éric Araujo : -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Antoine Pitrou : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1491] BaseHTTPServer incorrectly implements response code 100

Neil Muller added the comment: And a py3k version (although the conversion can be improved). -- Added file: http://bugs.python.org/file16653/BaseHTTPServer_continue_3_py3k.patch ___ Python tracker

[issue1491] BaseHTTPServer incorrectly implements response code 100

Neil Muller added the comment: Poking the issue with an updated patch for trunk. -- Added file: http://bugs.python.org/file16652/BaseHTTPServer_continue_3.patch ___ Python tracker __

[issue1491] BaseHTTPServer incorrectly implements response code 100

Neil Muller <[EMAIL PROTECTED]> added the comment: The attached patch is against recent svn (r64442), and adds samwyse's refactoring of the class. The test for server responses is made less restrictive when the request isn't HTTP/1.1. -- nosy: +Neil Muller Added file: http://bugs.python.

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Simon Cross <[EMAIL PROTECTED]>: -- nosy: +hodgestar __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1491] BaseHTTPServer incorrectly implements response code 100

samwyse <[EMAIL PROTECTED]> added the comment: In the attached file, I've refactored the entire BaseHTTPRequestHandlerTestCase class. In doing so, I couldn't help but notice that we're expecting HTTP/1.1 responses when sending HTTP/1.0 requests. RFC 2616 is unclear about whether this is legitim

[issue1491] BaseHTTPServer incorrectly implements response code 100

samwyse <[EMAIL PROTECTED]> added the comment: Although any given implementation of an HTTP server is likely to serve up its headers in a predicable, repeatable, order, I don't think that we should specify a particular order in the test suite. Section 4.2 of RFC 2616 specifically states, "The or

[issue1491] BaseHTTPServer incorrectly implements response code 100

Jeremy Thurgood <[EMAIL PROTECTED]> added the comment: The above patch adds a set of tests for BaseHTTPServer, although the only tests actually written were those around the areas touched by the work done for this issue. __ Tracker <[EMAIL PROTECTED]>

[issue1491] BaseHTTPServer incorrectly implements response code 100

Jeremy Thurgood <[EMAIL PROTECTED]> added the comment: Added handling for "Expect: 100-continue" header to BaseHTTPRequestHandler. By default, any request that has this header gets a 100 Continue response (with no other headers) before do_WHATEVER() is called. By overriding handle_expect_100(), y

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by Georg Brandl: -- keywords: +easy __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue1491] BaseHTTPServer incorrectly implements response code 100

Guido van Rossum added the comment: Something for the bug day on Jan 19. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe

[issue1491] BaseHTTPServer incorrectly implements response code 100

Changes by vila: -- nosy: +vila __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailma

[issue1491] BaseHTTPServer incorrectly implements response code 100

samwyse added the comment: Refactoring sounds like a good idea. Someone would need to check how other web servers log this, if at all. You're probably right about the HTTP/0.9 as well. The main reason to send a 100 response is because the client sent an "Expect: 100-continue" header, and won't

[issue1491] BaseHTTPServer incorrectly implements response code 100

Guido van Rossum added the comment: I'm not sure I understand why anyone would ever want to send a 100 response anyway. If I were to add support for this, I'd probably refactor send_response() so that there's a lower-level function send_response_only() that *only* sends the response header and c

[issue1491] BaseHTTPServer incorrectly implements response code 100

New submission from samwyse: RFC 2616 sec 8.2.3 states, "An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely." The obvious way to do this is to i