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

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

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 7 Jun 2018 11:26:53 +0200
To: Ben Campbell <ben@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-replay@ietf.org, Patrick McManus <mcmanus@ducksong.com>, httpbis-chairs@ietf.org, ietf-http-wg@w3.org
Message-ID: <20180607092653.GC19820@1wt.eu>
Hi Ben,

On Wed, Jun 06, 2018 at 12:23:31PM -0700, Ben Campbell wrote:
> Just some minor (mostly editorial) comments:
> 
> Substantive:
> 
> 3, item 2:  It seems odd to find "reject early data" in a list of mitigation
> strategies for servers that enable early data.

It's been clarified in the PR Martin added after your and Eric's review,
it now says "at the TLS layer". Indeed, technically a server could decide
when finding these early data whether it wants to accept or reject them
when receiving them. It may just be a matter of implementation.

> Editorial and Nits:
> 
> 3, latter part: There's a tendency to use language that gives anthropomorphic
> agency to inanimate objects or concepts. I find that a bit jarring. (e.g., "if
> resources do elect" and "server instances need to consider"
> 
> 5.1: "An intermediary MUST use the "Early-Data" header field if it might have
> forwarded the request prior to handshake completion (see Section 6.2 for
> details)." - inconsistent tense. (after forwarding seems a bit late to add the
> header field.)

I'll leave this to native english speakers who will know better than me.

> 5.2: "425 (Too Early): Are there degrees of earliness?

We've had some bikeshedding discussions on this one. I also proposed clearer
(to me) alternatives which were longer such as "Early Data Not Acceptable",
and in the end we really don't care since for a few decades, humans have
stopped reading reasons. We've thought about other ones like "Unsafe" but
it doesn't say why it's unsafe and will cause confusion if we later want
to add other "unsafe" reasons. So let's keep the short one, especially to
gracefully handle situations where we could expect that batches of pipelined
requests would get rejected at once.

> 6.1: " A gateway that forwards requests that were received in early data
>    MUST only do so if it knows that the origin server that receives
>    those requests understands"
> Consider "MUST NOT unless...". "MUST ONLY" can be ambiguous whether it means
> don't do it unless the condition occurs, you are only required to do it when
> the condition occurs, or you must do that and nothing else when the condition
> occurs.

I definitely agree with this one, it would indeed be clearer this way. I
suggest this :

    A gateway MUST NOT forward requests that were received in early data
    unless it knows that the origin server it will forward to understands ...

Thanks,
Willy
Received on Thursday, 7 June 2018 09:27:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC