- From: Rick Byers <notifications@github.com>
- Date: Wed, 10 Jan 2018 02:37:12 +0000 (UTC)
- To: whatwg/xhr <xhr@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 10 January 2018 02:37:34 UTC
>From the discussion at TPAC (unfortunately not minuted due to WiFi being too flaky) there was talk of limiting the compat risk by choosing a failure mode that's similar to failures that most uses of XHR are likely to already handle (eg. network errors). We specifically want to reduce the severity of breakage in unprepared iframes (eg. AMP is prepared to enable this), and try to maximize the chance we could enable this mode by default at some point. I don't have any hard data, but I suspect many uses of XHR are not prepared for open to throw an exception but are prepared for network errors. If that is true, then having open throw for this would greatly decrease the chance that embedders could apply this policy to arbitrary iframes, or that we could ever make this the default. What about treating it similarly to an [explicit abort](https://fetch.spec.whatwg.org/#concept-response-aborted)? I see that developer errors like calling `open` on an already open XHR are treated like abort, so maybe it's reasonable for attempting a sync XHR when sync is disabled to be treated similarly? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/xhr/issues/178#issuecomment-356482102
Received on Wednesday, 10 January 2018 02:37:34 UTC