Definitely a suggestion I should have made when I first saw that we were going to have backwards incompatibility this release!
Robby On Sat, Feb 1, 2020 at 12:27 PM John Clements <[email protected]> wrote: > > 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/CAL3TdON2_NRUbAGRKfzvKVZ7Fq-U6CvfO7bc6KbfPThcTd-yaw%40mail.gmail.com.
