That makes sense to me, but only if Philip has time to write that section. It also opens up a bit of a can of worms in that I’m not sure whether the docs currently has a good place for “discussion of changes relevant to a particular release.” I guess I was thinking that just appending it to the release notes would be simpler.
John > On Feb 1, 2020, at 10:22, Robby Findler <[email protected]> wrote: > > For this particular issue, I think that a section in the webserver > docs that includes things like: how to adjust your old webserver setup > to the new, explains why you might not want to do that, and more > broadly discusses the threats and how the defaults are a good > compromise would be really great. And people will find it, I think, > even without a pointer explicit from the release notes. Still, > explicit pointers in the the release notes for backwards incompatible > changes do seem like good practice. > > Robby > > On Sat, Feb 1, 2020 at 12:20 PM 'John Clements' via Racket Developers > <[email protected]> wrote: >> >> Wouldn't it make sense to add a footnote to the release notes with a URL or >> more detailed information? I know, this sounds nuts. In my mind, though, the >> main body of the release notes should be short enough to skim to see whether >> there’s anything interesting, but I don’t see a better place to put the >> deeper information. >> >> John >> >>> On Feb 1, 2020, at 10:12, Robby Findler <[email protected]> wrote: >>> >>> Looks like two bullets to me. Here's an edit: >>> >>> >>> * The Web Server provides fine-grained control over various aspects of >>> handling client connections (timeouts, buffer sizes, maximum header >>> counts, etc.) via the new "safety limits" construct. >>> >>> * The web server's default level of trust in client connections is >>> lower. Resource-intensive applications may need to adjust the >>> defaults (e.g., to accept large file uploads). >>> >>> I don't think anything I eliminated is essential for the release notes >>> (keeping in mind that many will learn about this when their website >>> doesn't work anymore -- they won't read the release notes at that >>> point I expect ....) >>> >>> Robby >>> >>> >>> Robby >>> >>> >>> On Sat, Feb 1, 2020 at 11:35 AM 'John Clements' via Racket Developers >>> <[email protected]> wrote: >>>> >>>> This bullet is a teensy bit bulky, but I stared at it for a few minutes >>>> and… I’d rather switch than fight. I guess that’s why I’m not a Tareyton >>>> smoker. >>>> >>>> John >>>> >>>>> On Jan 27, 2020, at 11:23, Philip McGrath <[email protected]> >>>>> wrote: >>>>> >>>>> On Mon, Jan 27, 2020 at 11:28 AM Matthew Flatt <[email protected]> wrote: >>>>> I would also highlight that the web >>>>> server change is technically not backward-compatible. >>>>> … >>>>> * The Web Server provides fine-grained control over various aspects of >>>>> handling client connections (timeouts, buffer sizes, maximum header >>>>> counts, etc.) via the new "safety limits" construct. >>>>> >>>>> Using this new construct, we have decreased the web server's default >>>>> level of trust in client connections and made it detect additional, >>>>> maliciously constructed requests. To get the old behavior for use in >>>>> trusted settings, start the web server with `#:safety-limits >>>>> (make-unlimited-safety-limits)`. >>>>> >>>>> It isn't only fully trusted settings that need to pay attention: for >>>>> example, if you expect non-malicious file uploads larger than 10 MiB, you >>>>> will need to make an adjustment. >>>>> >>>>> Also, `(make-unlimited-safety-limits)` isn't quite the old behavior: I >>>>> wouldn't get into this level of detail in the announcement, but the >>>>> default behavior was closest to `(make-unlimited-safety-limits >>>>> #:request-read-timeout 60)`, or, if you'd provided optional arguments >>>>> `max-waiting` and `initial-connection-timeout` (which weren't accepted at >>>>> all entry points), `(make-unlimited-safety-limits #:request-read-timeout >>>>> initial-connection-timeout #:max-waiting max-waiting)`. (This is in the >>>>> docs in even more detail.) >>>>> >>>>> For those who haven't followed this discussion, there was a conflict here >>>>> between wanting to provide safe defaults and strict backwards >>>>> compatibility. The new construct gives programmers the ability to specify >>>>> how they want to balance these concerns in the future, with >>>>> `make-unlimited-safety-limits` meaning "don't impose any limits I haven't >>>>> explicitly listed." This time, though, we had to make a choice, and >>>>> safety seemed like the right choice for most cases, especially if you >>>>> interpret the old behavior as "we'll try to do the right thing generally, >>>>> and here are just a couple of tuning knobs." >>>>> >>>>> Here's an attempt at putting that into a bullet: >>>>> >>>>> * The Web Server provides fine-grained control over various aspects of >>>>> handling client connections (timeouts, buffer sizes, maximum header >>>>> counts, etc.) via the new "safety limits" construct. >>>>> >>>>> Using this new construct, we have decreased the web server's default >>>>> level of trust in client connections and made it detect additional, >>>>> maliciously constructed requests. Resource-intensive applications may >>>>> need to adjust the default limits (for example, to accept large file >>>>> uploads). >>>>> In trusted settings, they can be disabled completely by starting the web >>>>> server >>>>> with `#:safety-limits (make-unlimited-safety-limits)`. >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Racket Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/racket-dev/CAH3z3gbLfyjE5F-BdNj5MbjBkihJgL65kKjZbZf3%3Dtd_cV8%3D1g%40mail.gmail.com. >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Racket Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/racket-dev/d6371e41-40f1-4340-b5e4-302706ae34a5%40mtasv.net. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/d19d804a-f98f-4b65-acf0-3f0c9d346f80%40mtasv.net. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/CAL3TdOO7m_aG0a3L5%3D%2BqZg0fZAfenD-LUA9F-x6hy78N2FZesg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/c108fe21-df44-4b64-ab3c-c2078b74298e%40mtasv.net.
