[issue25919] http.client PUT method ignores error responses sent immediatly after headers
Wiktor Niesiobedzki added the comment: Here are the test cases that I've come up with. test_response_after_headers - tests for the case that I'm missing test_ssl_renegotiation - tests for the case that Martin point out As in stock ssl library there is no way to force renegotiation, I've just separated the receiving of standard HTTP status message into few parts and checking, if the http.client is still sending the contents. So - without my patch, first case is failing, with my patch - the second case is failing. I'll try to find some better solution here, which will cover both cases. -- Added file: http://bugs.python.org/file41573/early_http_response_tests.patch ___ Python tracker <http://bugs.python.org/issue25919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25919] http.client PUT method ignores error responses sent immediatly after headers
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: DM2304PAP130 < Strict-Transport-Security: max-age=31536000; includeSubDomains < X-ThrowSite: 7c11.e25d < Date: Mon, 04 Jan 2016 18:44:28 GMT > [...] 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 <http://bugs.python.org/issue25919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25919] htp.client PUT method ignores error responses sent immediatly after headers
Wiktor Niesiobedzki added the comment: Here is revised patch. Also covers changes to tests. -- Added file: http://bugs.python.org/file41392/http.client.put.fix.patch ___ Python tracker <http://bugs.python.org/issue25919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25919] htp.client PUT method ignores error responses sent immediatly after headers
Wiktor Niesiobedzki added the comment: Maybe something like this? Doesn't look too complicated and I haven't noticed any breakage yet. -- keywords: +patch Added file: http://bugs.python.org/file41390/http.client.put.fix.patch ___ Python tracker <http://bugs.python.org/issue25919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25919] htp.client PUT method ignores error responses sent immediatly after headers
New submission from Wiktor Niesiobedzki:
It looks like, when doing PUT together with a file-like object to send,
http.client will try to send the whole file before analysing the response from
the server.
If you do the following:
$ dd if=/dev/zero of=/tmp/300mb.zero bs=1M count=300
And then run following code in Python 3.4 (tested 3.4.3 on Linux and FreeBSD):
import http.client
conn = http.client.HTTPSConnection('api.onedrive.com')
req = conn.request(
method='PUT',
url='https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content',
body=open("/tmp/300mb.zero", "rb"))
resp = conn.getresponse()
You'll notice the hang. After some time, it will aborted with BrokenPipeError:
[Errno 32] Broken pipe. If you run the following code within pdb debugger, and
interrupt, you'll probably interrupt somewhere within write loop. You can call
self.read() and see, that HTTP 413 is waiting to be interpreted.
Doing similar action with curl:
$ $ curl -v -T /tmp/300mb.zero
https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content
Gives you immediate HTTP 413 error. Can we have the same behaviour in
http.client library?
--
components: IO
messages: 256808
nosy: Wiktor Niesiobedzki
priority: normal
severity: normal
status: open
title: htp.client PUT method ignores error responses sent immediatly after
headers
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue25919>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
