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