W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Adam Roach's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 7 Jun 2018 09:35:28 +0200
Message-ID: <CABkgnnUkBpJeug0R2fsHJtw6XTqztp-ymJ97dcdB3EAhG=gF0w@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC