- From: Adam Rice <notifications@github.com>
- Date: Mon, 12 Aug 2024 21:16:20 -0700
- To: whatwg/encoding <encoding@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/encoding/issues/334/2285307862@github.com>
In practice browsers have already abandoned consistent behaviour here, as some OOM failures cause more pain for users than others. XHR is particularly terrible in Blink, as it just silently replaces the response with an empty response in case of OOM. In this specific case, there's no danger of leaving the user agent in an inconsistent state, as we have to do the allocation before anything else. However, user JavaScript may still be in an inconsistent state. In general, the exception will stop it continuing with erroneous calculations, but if it happens to be catching and discarding exceptions when `encode()` is called that could be dangerous. I recognize the wisdom of the oom-fails-fast proposal, but it doesn't reflect what engines actually do. I've had to fix security holes in Blink caused by stack overflow throwing an exception in places that the standard says should never throw. My philosophy is that OOM should continue to crash in most cases, but we need to pragmatically carve out exceptions in cases that cause particular user pain. As such, I'd like to attempt convergence between browsers on those exceptions, and one way to do that is to specifically mention them in the relevant standards. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/encoding/issues/334#issuecomment-2285307862 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/encoding/issues/334/2285307862@github.com>
Received on Tuesday, 13 August 2024 04:16:24 UTC