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

[Adam Roach <[e-mail]>]

After your explanations, this makes perfect sense, and upon re-reading the original text, I’m not sure why I misread it. Sorry for the noise.

/a

> On Jun 7, 2018, at 02:35, Martin Thomson <[e-mail]> wrote:
> 
> 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.