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 <ro...@cs.northwestern.edu> 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 > <racket-dev@googlegroups.com> 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 <ro...@cs.northwestern.edu> 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 >>> <racket-dev@googlegroups.com> 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 <phi...@philipmcgrath.com> >>>>> wrote: >>>>> >>>>> On Mon, Jan 27, 2020 at 11:28 AM Matthew Flatt <mfl...@cs.utah.edu> 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 racket-dev+unsubscr...@googlegroups.com. >>>>> 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 racket-dev+unsubscr...@googlegroups.com. >>>> 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 racket-dev+unsubscr...@googlegroups.com. >> 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 racket-dev+unsubscr...@googlegroups.com. > 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 racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/c108fe21-df44-4b64-ab3c-c2078b74298e%40mtasv.net.
