Dear all, Applications have always had to deal with the occasional replay, whether from an impatient user or a broken connection at exactly the wrong time. But they've generally been rare, so human-in-the-loop responses work. Order the same book twice? Just return one of them, and if you get an overdraft fee, ouch, we're sorry, but nothing we can do.
0-RTT is opt-in per protocol, and what we think of per application. But it isn't opt-in for web application developers. Once browsers and servers start shipping, 0-RTT will turn on by accident or deliberately at various places in the stack. At the same time idempotency patterns using unique IDs might require nonidempotent backend requests. But this is an easier problem than if we had nonidempotent brower requests: backends are much more controlled. If you are willing to buffer 0-RTT until completion before going to the thing that makes the response, you can handle this problem for the responsemaker. This will work for most applications I can think of, and you need to handle large, drawn out requests anyway. This sounds like it would work as a solution, but I am sure there are details I haven't discovered yet. In conclusion I think there is some thought that needs to go into handling 0-RTT on the web, but it is manageable. I don't know about other protocols, but they don't have the same kinds of problem as the web does with lots of request passing around. Given the benefits here, I think people will really want 0-RTT, and we are going to have to figure out how to live with it. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
