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.
