- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 24 Nov 2017 04:48:55 +0100
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, mnot <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>
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. > 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
Received on Friday, 24 November 2017 03:49:32 UTC