[longlho]

canceling GET is the simplest use case, XMLHttpRequest/fetch is already able to abort. POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)

[lomnakkus]

> POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)

If those can corrupt state then you're already at the complete mercy of the network... which is never a good idea regardless of whether this proposal is accepted or not.

[longlho]

yup, so why bloat up the spec? Introducing a 3rd option that represents a non-deterministic remote state isn't entirely helpful IMO. Having the ability to abort the connection should be enough (which is a rejection).

[lomnakkus]

Hm? My point was that the spec doesn't fundamentally change anything wrt. the things you mentioned, so it should be evaluated on other merits (or lack thereof).

Doing ad-hoc hacks around the lack of cancellation seems like a pretty big practical issue to me[1], so I'd certainly like to see something like this spec in the standard.

(Note: something like, not necessarily exactly this. I haven't thought about it deeply enough to be able to properly evaluate the spec.)

[1] Happens all the time when doing simple Ajax-on-futures where you really just want to ignore any result if the operation gets canceled in the UI before the response arrives.