Retry safety of HTTP requests

HTTP/1.1 and the current HTTP/2 spec don't define the concept of retry safety of requests, i.e. when are requests are safe to retry and what are the limits on how retries can be performed by the lower layers.

I believe this is a new item and I'm trying to gauge people's interest in this topic, and whether such an idea has been explored before in the httpwg.

I think defining retry safety will become an important problem in the near future. I can see several use cases if we have a proper definition of retry safety in HTTP:

1) Usually an application like a piece of javascript will create a HTTP request and send it to a browser or mobile app which executes it. The browser or a mobile app might want to retry the request. In unreliable networks, retrying requests is important for reliability. The application could decide that it would create a non idempotent request like a POST, and have an application layer mechanism to enforce idempotence. It could then tell the browser that the request was retry safe because it was enforcing idempotence, and let the browser perform optimizations to retry it depending on network conditions, including caching the request offline, retrying when the network comes back, sending the request across 2 connections on different interfaces, etc.

2) Some transport protocols which treat retry safe requests differently from non retry safe requests. For example in TLS 1.3, idempotent requests may be sent in a 0-RTT flight, which reduces the latency for the request. An application might desire a non idempotent request which is retry safe be sent in this 0-RTT flight.

3) A non-application server such as a load balancer might also desire to know whether or not the client expressed that this request is retry safe so that it may retry this request if the backend fails over offering more reliability to clients.

Currently, the only semantics for an application to express retry safety is via idempotency (the request method). The status quo shows that even this is not expressive enough, since even though GETs are not technically idempotent, some browsers will retry them anyway.

Having an document which would define a new property like retry-safety would help apps take advantage of reliability features of browsers for requests other than GETs and also prepare HTTP to be able to use TLS1.3 effectively.

In our Facebook mobile apps we annotate all the requests that our app makes as retry safe or not and that helps us decide how retry policies should behave for each request. It's been very useful for request reliability.

Would the HTTP-wg be interested in a document describing retry-safety and its limitations?

Cheers,
Subodh Iyengar