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

Thanks Adam,

PR here:

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