Re: Working Group Last Call for Using Early Data in HTTP

Hi Willy,

2017-11-24 12:48 GMT+09:00 Willy Tarreau <w@1wt.eu>:

> Hi Kazuho,
>
> On Fri, Nov 24, 2017 at 12:27:59PM +0900, Kazuho Oku wrote:
> > Section 4 has the following paragraph.
> >
> > > An intermediary MUST NOT use early data when forwarding a request
> unless
> > early data was used on a previous hop, or it knows that the request can
> be
> > retried safely without consequences (typically, using out-of-band
> > configuration).  Absent better information, that means that an
> intermediary
> > can only use early data if the request either arrived in early data or
> > arrived with the "Early-Data" header field set to "1" (see Section 5.1).
> >
> >
> > Could I ask why an intermediary is allowed to forward early data if it
> "was
> > used on a previous hop"?
>
> It's simply because there is a guarantee that either an intermediary before
> it or the client will be able to deal with 425 if one such happens.
>

Thank you very much for the clarification. Now I understand.

The assumption I missed is that by enabling the intermediary to reconnect
with 0-RTT (through the use of EarlyDataIndication is NewSessionTicket
message) the origin server is opting-in to use early data.


>
> > Shouldn't an intermediary wait for the handshake completion or send 425
> in
> > case it is unsure if the request can be retried safely?
> >
> > My understanding is that the intent of the draft it to make use of
> > early-data an opt-in feature from server's perspective. This guidance for
> > the intermediary seems to contradict with the principle.
>
> Not at all. What matters is that if the server is not willing to serve a
> request coming as early data, it will send a 425 inviting the client or
> any intermediary to resend without early data. So if a middle agent decides
> to use early data to join the server, it needs to be certain either to be
> able to retry itself, or that someone else will retry for it. Receiving
> a 425 in this case with the proof that another agent will retry is enough.
>
> Hoping this helps,
> Willy
>



-- 
Kazuho Oku