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.
