Curl uses “Expect: 100-continue”. This is the relevant output from it:

$ curl -v -T 300mb --no-fail https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content
[. . .]
> 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: */*
> Connection: TE
> TE: gzip
> Content-Length: 314572800
> Expect: 100-continue
> 
< 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: DM2302____PAP179
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-ThrowSite: 7c11.e25d
< Date: Sun, 03 Jan 2016 20:04:27 GMT
* HTTP error before end of send, stop sending
< 
* Closing connection 0

See Issue 1346874 about support for 100-continue mode.

When I tried your test code on Linux, it hung for two minutes, and then raised ConnectionResetError. I guess the server refused to receive data, and then timed the connection out. The patch should handle this in most cases, but I think there could still a race between select() returning an empty rlist, and then the server sending a request and causing the upload to hang. Also, there is nothing to protect from sendall() partially uploading a chunk, and then hanging.

It should be more robust to check for both send and receive sides of the socket with select(), and only use send(), not sendall(), to avoid blocking.

I would consider this a new feature, so I don’t think it should go into 3.5. It would be good to add documentation and test cases as well.

Wiktor’s problem is similar to the situations in Issue 5542. There, the original poster seemed happy to wait for a broken pipe error, and then inspect a 401 Unauthorized response. This apparently was made to work with plain HTTP over TCP, but not HTTPS.

I wonder if having request() silently return is the best API design. Is there a possibility that the caller would want to distinguish a successful upload from an aborted one? I can’t think of one, but it seems plausible.

Another related enhancement I would like is the ability to detect an error response (e.g. 408 Request Timeout) or dropped connection _before_ even sending a request. This is useful with persistent connections; see items 1 and 2 in <https://bugs.python.org/issue9740#msg240459>.