On Thu, Jun 07, 2018 at 11:21:28AM -0500, Benjamin Kaduk wrote: > On Thu, Jun 07, 2018 at 11:05:03AM +0200, Willy Tarreau wrote: > > On Thu, Jun 07, 2018 at 10:45:36AM +0200, Martin Thomson wrote: > > > Thanks for reviewing ekr, > > > > > > PR here: https://github.com/httpwg/http-extensions/pull/647 > > > > > > On Thu, Jun 7, 2018 at 9:49 AM Eric Rescorla <ekr@rtfm.com> wrote: > > > > S 3. > > > > > A server can limit the amount of early data with the > > > > > "max_early_data_size" field of the "early_data" TLS extension. This > > > > > can be used to avoid committing an arbitrary amount of memory for > > > > > deferred requests. A server SHOULD ensure that when it accepts early > > > > > data, it can defer processing of requests until after the TLS > > > > > handshake completes. > > > > > > > > I don't understand this last line. You don't have to defer, so why > > > > should you ensure that? > > > > > > Mark, Willy, I'm inclined to cull this paragraph. It's a hang-up from > > > the time we thought that deferring was our best defense, I think. > > > I've included that change in the PR. > > > > I agree. Some might decide that whatever they process is safe for early > > data and that they don't want to defer. > > I agree that the SHOULD is not needed, but wonder if there is value > in retaining some statement along the lines of "servers that choose > to buffer have a knob available to control how big of a buffer they > need to reserve". 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. It's not critical though, but I definitely think it's easier to find in an HTTP-related spec than in the TLS one for most HTTP implementers. Regards, WillyReceived on Thursday, 7 June 2018 16:28:33 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC