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

Hi Benjamin,

Thank you for your response.

2017-07-25 21:27 GMT+09:00 Benjamin Kaduk <bkaduk@akamai.com>:
> On 07/25/2017 02:29 AM, Kazuho Oku wrote:
>
> 2017-07-25 15:54 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:
>
>
> I think that the following model would be safe:
>
> * consider 4NN as a signal that indicates the intermediary to wait for
> 1-RTT confirmation and retry
> * 1-RTT confirmation can be observed as a logical and of
> ClientFinished and non-existence of the early-data header
>
> I do not see any reason to send 4NN to the initiator of the request
> (i.e. browser), since the peer that the initiator talks to can always
> use the ClientFinished as a confirmation. As I said, transmitting 4NN
> to the initiator can impose additional latency, since contrary to
> ClientFinished a client cannot (re)send a request until it sees the
> response.
>
>
> That seems like it would violate the principle that the actual client
> generating the request should have control over whether it is retried.
>
> To be precise, what I am suggesting here is that the server's action
> for processing a request without replay-torelance can be defined as
> follows:
>
>
> I assume that by "without replay-torelance [sic]" you mean a request that
> has potentially replay-unsafe consequences/side effects, so the request must
> only be acted on over non-replayable transport.
>
> * 0-RTT request with early-data header: send 4NN
>
>
> Yes.
>
> * 0-RTT request with no early-data header: postpone request processing
> until ClientFinished
>
>
> That seems permissible, but sending 4NN is also fine and requires less state
> on the server.
>
> * 1-RTT request with early-data header: send 4NN
>
>
> Yes.
>
> * 1-RTT request with no early-data header: process the request
>
>
> Yes.
>
> and that it can be deducted from the rule that when receiving a 0-RTT
> request without an early-data header, an intermediary should: forward
> the request to the origin by adding an early-data header, and if the
> origin refuses to process the request by responding with 4NN, it
> should wait (i.e. postpone the processing of the request) for
> ClientFinished and resend the request to the origin server (this time
> without the early-data header).
>
>
> 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.

Could you please clarify the reason that an intermediary should not be
allowed to retry a request (that has once been rejected by 4NN) when
receiving an 1-RTT confirmation from client, without setting the
early-data header?

To me, the behavior is identical to a server that postpones a request
(that was received as 0-RTT data) until it sees a ClientFinished.
Which is a behavior you state as permissible.

> -Ben



-- 
Kazuho Oku

Received on Tuesday, 25 July 2017 15:30:50 UTC