- From: Luca Casonato <notifications@github.com>
- Date: Sat, 04 Feb 2023 02:20:25 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1592/1416715878@github.com>
> I wonder if ServiceWorkers would benefit? @ricea Possibly. I agree that in browsers the need for this is less evident, because the worst thing a DOS in a service worker can do is take down one origin for one user momentarily. On servers however, this DOS vector can take down one origin for all users. > Is there evidence of use in libraries or requests for this functionality on Stack Overflow? @annevk I can not find requests on Stack Overflow, but there have definitely been CVEs related to request body parse handling in server-side JS runtimes and libraries. Fastify, a popular Node.js server framework, has an option to specify a maximum body size for requests. Similar options exist for express and many other frameworks. > Can this be something like "a limit chosen by user agent" instead of a user given limit? @saschanaz We already imply this through this sentence in the infra spec: > [...] user agents may impose [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) limits on otherwise unconstrained inputs. E.g., to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. > > _From https://infra.spec.whatwg.org/#algorithm-limits_ The idea behind a specific limit option for us is that we'd like to set a reasonable default limit, but provide our users with an opt-out mechanism to specify a higher limit in case they need it. For us it is impractical to have a limit that is not in any way opt-out by the user. --- There is a very strong need for this from both Deno and Cloudflare Workers, and it would be great if for parity's sake browsers matched behaviour here. Hypothetically, if the implementation work in browsers is contributed by us, would you be more inclined to consider this? This is the path we are taking with #1346: - there is a need in server-side runtimes for this - we wrote the spec and tests - browsers were generally open to the idea, as long as they didn't have to put in the work to implement - as a consequence: Bloomberg sponsored Igalia to do the implementation work in browsers -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1592#issuecomment-1416715878 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/issues/1592/1416715878@github.com>
Received on Saturday, 4 February 2023 10:20:38 UTC