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

Re: Eric Rescorla's No Objection on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 8 Jun 2018 12:10:13 +0200
Message-ID: <CABkgnnUZzLrCLhONL=nGJZab0PM=bHJbz5ar99RtSV29VYdaKA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Benjamin Kaduk <kaduk@mit.edu>, httpbis-chairs@ietf.org, Eric Rescorla <ekr@rtfm.com>, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-replay@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jun 7, 2018 at 6:28 PM Willy Tarreau <w@1wt.eu> wrote:
> While usually I wouldn't suggest such apparently trivial stuff, here
> we're speaking about having such a buffer available at a very unexpected
> moment or place in an implementation, and I think that placing such a
> warning regarding the impacts of using early data in existing code, and
> explaining how to adjust it could save a number of people from trying and
> wasting their time if it's not designed at all to accept this.

This isn't an easy answer, because the amount of space you need
depends on how you buffer as well as a bunch of other factors.  For
instance, if you buffer into parsed structures, accounting for
buffering is not directly related to the number of octets you receive.

And there is the mix of traffic you might expect to receive, if you
get lots of requests that would be considered safe, maybe allowing for
a larger buffer is OK if you are willing to send 425 in the case that
you run out of space.

At some point we have to leave it to people to do some engineering and
I think that this is one of those cases.  The advice we would give
would be at best imperfect, but probably quite wordy.  Better to deal
with this on a blog posting, server configuration documentation, or
something else.
Received on Friday, 8 June 2018 10:10:48 UTC

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