Author Wiktor Niesiobedzki
Recipients SilentGhost, Wiktor Niesiobedzki, martin.panter, r.david.murray
Date 2016-01-04.20:13:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I've checked how it behaves, when I do:
$ openssl s_client -host -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:
> 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
< 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.
Date User Action Args
2016-01-04 20:13:02Wiktor Niesiobedzkisetrecipients: + Wiktor Niesiobedzki, r.david.murray, SilentGhost, martin.panter
2016-01-04 20:13:02Wiktor Niesiobedzkisetmessageid: <>
2016-01-04 20:13:02Wiktor Niesiobedzkilinkissue25919 messages
2016-01-04 20:13:01Wiktor Niesiobedzkicreate