Re: New Version Notification for draft-thomson-http-replay-00.txt

On 07/25/2017 10:44 PM, Willy Tarreau wrote:
> So while we designed the 4NN principle as an end-to-end invitation to
> retry, offering the guarantee that the request was not processed and
> that it will not be replayed, this same signaling is perfectly usable
> between components. The fact that the client isn't notified of the
> intermediary retrying it is not a problem because if the client has
> sent its request in 0-RTT and has sent its ClientFinished, it's because
> it expected it to be completed. By the way that was the recommended way
> to implement 0-RTT before we discussed this at the workshop ;-)

I just want to point out that 4NN was not a *guarantee* that the request
will not be replayed until
https://github.com/martinthomson/http-replay/pull/25 added text that the
server MUST consistently use the same approach, if I understand things
correctly.  That is, draft-thomson-http-replay-00 leaves open the
possibility for one server in a cluster to return 4NN and another server
in that cluster to have a different level of load (or whatever) and
successfully process the request.

> However, I'm not willing to open the draft to let intermediaries retry
> in the general case, at least for the reasons Ben mentionned and because
> for me there is a difference between the specific model above where we
> consider the intermediary as part of the server system and many other
> models. I'd rather not see blackboxes decide to do whatever on the
> client's behalf as a way to "accelerate" networks...
>
> But I think that by using a careful wording we can ensure that implementers
> who consider themselves as part of the server system see what to do in their
> situation. We can possibly put a few MUST NOT rules for specific cases which
> risk to become border-line.
>

I agree with Martin that this is pretty convincing, and hope we can come
up with appropriately flexible language that maintains the other
properties we're looking for.

-Ben