This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Michal Arbet, an7e, gvanrossum, martin.panter
Date 2020-07-28.05:47:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1595915234.81.0.940515924804.issue41345@roundup.psfhosted.org>
In-reply-to
Content
Previous report about Requests to the Python bug tracker: Issue 33620.

I suspect this is an unavoidable race condition with trying a POST (or other non-idempotent) request on an idle HTTP connection. I think it has to be up to the higher-level application or user to decide if it is safe to retry a POST request. Otherwise you risk e.g. accidentally ordering two pizzas because the server received two POST requests but something interfered with the response of the first response. On the other hand, I noticed some browsers seem to automatically retry a POST once if it is interrupted, which makes me uneasy.

A concrete example of the problem is a firmware upload that triggers a reboot. If the reboot is too quick and prevents the POST response being sent, I found that a web browser will repeat the firmware upload once more after my firmware boots up again.

If it is not safe to retry the POST request, other options would be to avoid the server thinking the connection is stale:

* always do the POST request on a fresh HTTP connection
* "ping" the connection with a dummy request (e.g. OPTIONS, HEAD, or GET) immediately before the POST request

Another option that comes to mind is to try using the 100 Continue mechanism, but this is not a general solution and depends on the application.
History
Date User Action Args
2020-07-28 05:47:14martin.pantersetrecipients: + martin.panter, gvanrossum, an7e, Michal Arbet
2020-07-28 05:47:14martin.pantersetmessageid: <1595915234.81.0.940515924804.issue41345@roundup.psfhosted.org>
2020-07-28 05:47:14martin.panterlinkissue41345 messages
2020-07-28 05:47:14martin.pantercreate