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

On 07/25/2017 07:36 AM, Willy Tarreau wrote:
> On Tue, Jul 25, 2017 at 07:27:02AM -0500, Benjamin Kaduk wrote:
>> This part I do not agree with, in particular the intermediary making the
>> decision to re-send the request without the early-data header.  I
>> believe that this decision must be left in the hands of the original
>> client, and do not think the latency concern justifies deviating from that.
> In fact the client has no idea about the request's semantics nor safety,

I think "no idea" is hyperbole, and maybe not helpful.  The application
server is the only one that has any hope of being authoritative, of
course (but could still be "confused about it" for certain types of side

> only the application server does. The client may only approximate this
> based on the method, the presence or not of a query string, etc... anything
> that anyone else in the chain has access to and that is suboptimal. That's
> why the 4NN generated by the server provides the best safety here : if there
> is a risk that the server experiences a replay, it means it has accepted the
> request carrying the Early-Data header, meaning it was replay-safe. Otherwise
> the server would only process the only one without Early-Data.

I'm not sure I'm understanding you properly, particularly with respect
to "experiences a replay".  Please also keep in mind the distinction of
terminology between replay and retry that I've been trying to enforce.

With respect to my original claim, I am thinking along the lines of where a
client might have external reasons to defer the retry behavior.  (This
is not necessarily the only use case, of course.)


Received on Tuesday, 25 July 2017 13:42:14 UTC