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.
