Wiktor Niesiobedzki added the comment: I've checked how it behaves, when I do: $ openssl s_client -host api.onedrive.com -port 443
The server then works like that (using curl debug log style): > PUT /v1.0/drives/me/root:/test.file:/content HTTP/1.1 > Host: api.onedrive.com > Content-Range: bytes 0-314572799/314572800 > User-Agent: curl/7.43.0 > Accept: */* > Content-Length: 314572800 > < HTTP/1.1 413 Request Entity Too Large < Content-Length: 0 < Server: Microsoft-HTTPAPI/2.0 < P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo" < X-MSNSERVER: DM2304____PAP130 < Strict-Transport-Security: max-age=31536000; includeSubDomains < X-ThrowSite: 7c11.e25d < Date: Mon, 04 Jan 2016 18:44:28 GMT > 0000000000000000000000000000000000000000000000000000 [...] And I may continue sending the data. As for 100-continue - it looks like Microsoft server is not supporting Expect: 100-continue header, and it just waits for data, when content is shorter (like 100 bytes). I do not see clear indications how the client should behave in such situation (response received before sending complete request). I do not understand, where you see the race condition. As we are sending in blocks of 8kb, if we missed the select on first block, we will catch something in next select. If server would close down the socket immediately, we should receive failure in sock.sendall() -> writing to socket that is closed for writing by remote party. As I understand, right now my patch breaks uploads, when server returns HTTP 100 response. Contrary to Issue 1346874 I'd recommend to check - if server returned 100 response, then continue the upload of the file or prepare error response for get_response(). I do not see why this behaviour should be implemented in code using http.client. Status of upload should be (and it is right now) done using get_response() anyway, as any upload request might end in HTTP error response, so I vouch for empty return value - it is complaint with current interface. I'm in progress of preparation of the test cases for such scenario using SocketServer, to keep it close to how network behaves, but maybe I'll manage to prepare testcases using FakeSocket. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25919> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
