[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-07 Thread Susumu Koshiba
Susumu Koshiba added the comment: A patch for 3.5 attached. -- Added file: http://bugs.python.org/file43292/issue25738_http_reset_content_3.5_02.patch ___ Python tracker <http://bugs.python.org/issue25

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-07 Thread Susumu Koshiba
Susumu Koshiba added the comment: Great, thanks for checking. Attaching patch for 2.7. 3.5 will follow. -- Added file: http://bugs.python.org/file43291/issue25738_http_reset_content_2.7_02.patch ___ Python tracker <http://bugs.python.org/issue25

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-07 Thread Susumu Koshiba
Susumu Koshiba added the comment: Thanks for the suggestions, I've updated the test cases and created a patch for 3.6. -- Added file: http://bugs.python.org/file43277/issue25738_http_reset_content_07.patch ___ Python tracker

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-05 Thread Susumu Koshiba
Susumu Koshiba added the comment: Ah yes, you are right. I didn't think about the cases where it will send HEAD for codes like 204(No Content). I've created a patch for 3.6 to see if this looks reasonable, if review passes, I'll create patches for the rest of the releases. T

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: 3.6 patch(..._05.patch file) -- Added file: http://bugs.python.org/file43225/issue25738_http_reset_content_05.patch ___ Python tracker <http://bugs.python.org/issue25

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: 3.5 patch. -- Added file: http://bugs.python.org/file43224/issue25738_http_reset_content_3.5_01.patch ___ Python tracker <http://bugs.python.org/issue25

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: Thanks, makes sense to me. I've created patches for 2.7, 3.5, 3.6. 3.5's implementation looked slightly different from 3.6 so I've decided to create a separate patch, just in case. I will upload them 1 by 1 starting with 2.7. It will get a

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: Thanks again for valuable comments. I agree that there could be a case where send_error() gets used for both HEAD and GET, in which case we could send content-length field as an optional field. However, if send_error() is not used for both HEAD and GET, then

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: Sorry, re-created a patch to do the right word wrapping and made my comments less verbose. -- Added file: http://bugs.python.org/file43204/issue25738_http_reset_content_04.patch ___ Python tracker <h

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-04 Thread Susumu Koshiba
Susumu Koshiba added the comment: Thanks a lot for a quick review. I've created a new patch with below changes. 1. No content-length and the body to be sent for: a. 204(No Content) b. 205(Reset Content) c. 304(Not Modified) d. response to HEAD request method e. 1

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-03 Thread Susumu Koshiba
Susumu Koshiba added the comment: Thanks, I've added some comments to the doc and updated the patch. -- Added file: http://bugs.python.org/file43182/issue25738_http_reset_content_02.patch ___ Python tracker <http://bugs.python.org/is

[issue25738] http.server doesn't handle RESET CONTENT status correctly

2016-06-02 Thread Susumu Koshiba
Susumu Koshiba added the comment: Patched the behaviors when NO_CONTENT and RESET_CONTENT are sent via send_error(). According to RFCs, they aren't actually errors so sending them through send_response() seems to make the most sense, however. send_error()'s behavior changes in this