Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
___
Python-bugs-list mailing list
Senthil Kumaran orsent...@gmail.com 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
Changes by Senthil Kumaran orsent...@gmail.com:
--
assignee: - orsenthil
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
___
Changes by Mark Lawrence breamore...@yahoo.co.uk:
Removed file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
Changes by Mark Lawrence breamore...@yahoo.co.uk:
Removed file: http://bugs.python.org/file10278/BaseHTTPRequestHandlerTestCase.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
Changes by Mark Lawrence breamore...@yahoo.co.uk:
Removed file: http://bugs.python.org/file10684/BaseHTTPServer_continue_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
stage: - patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
___
Python-bugs-list mailing
Neil Muller drnlmuller+b...@gmail.com 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 rep...@bugs.python.org
Neil Muller drnlmuller+b...@gmail.com 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 rep...@bugs.python.org
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +orsenthil
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491
___
___
Python-bugs-list mailing
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:
Changes by Simon Cross [EMAIL PROTECTED]:
--
nosy: +hodgestar
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1491
__
___
Python-bugs-list mailing list
Unsubscribe:
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(), you
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]
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
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
Changes by vila:
--
nosy: +vila
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1491
__
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Something for the bug day on Jan 19.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1491
__
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
22 matches
Mail list logo
