- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 7 Jun 2018 09:35:28 +0200
- To: Adam Roach <adam@nostrum.com>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-replay@ietf.org, Patrick McManus <mcmanus@ducksong.com>, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Thanks Adam, PR here: https://github.com/httpwg/http-extensions/pull/646 I think that this is just a misunderstanding, but I'm happy to explore ways to make this clearer. > ยง5.2: > > > In all cases, an intermediary can forward a 425 (Too Early) status > > code. Intermediaries MUST forward a 425 (Too Early) status code if > > the request that it received and forwarded contained an "Early-Data" > > header field. Otherwise, an intermediary that receives a request in > > early data MAY automatically retry that request in response to a 425 > > (Too Early) status code, but it MUST wait for the TLS handshake to > > complete on the connection where it received the request. > > This seems correct but incomplete. > > I believe that we also want to (MUST-level) require the forwarding of the 425 > in the case in which an intermediary receives a request from a client in early > data (i.e., no "Early-Data" header field), forwards it towards the origin > (with an "Early-Data" header field), and then receives a 425 response. I > suspect the intention here was to cover that case in the "MUST" above, but > it's not what the text actually says. It's the opposite, as Willy says. Let me restate Willy's response more concisely.: 425 can be forwarded always. 425 is always forwarded if the inbound request contains Early-Data. 425 doesn't need to be forwarded if the request didn't contain Early-Data; the intermediary can instead absorb the 425 and retry the request after the inbound connection handshake completes. That's complete as near as I can tell.
Received on Thursday, 7 June 2018 07:36:16 UTC