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/CAL3TdOMq_XwQ%3DxHUEYwssDkQZ-9sioLnv-TEvgUBd2-siLBAvw%40mail.gmail.com.
