I think cancelling HTTP requests is quite a useful in some scenarios. Eg 1) Say you're fetching heavy json/binary data on an user action, and before data arrives, he changes his action. Not only do ypu download all of the extra data, but the fetch for the next action is slowed down like hell.

Not sure, but does this mean that I can't cancel a heavy file upload if a user changes his mind?

Herein lies the rub.

So I cancel my GET request, all is fine with the world. I cancel my POST, and now I have no idea at which layer it was cancelled, if at all. Certainly the cancel doesn't propagate to the server.

I've used cancellation in C# and agree that it's super useful, but it's not a panacea and has to be handled thoughtfully. JS can manage without it IMHO

The counter-argument to that is what happens when you make a GET request for a 1gb file? Or you POST a 1gb upload?

Canceling them is now a big deal if it's needed.

Personally, I think they could be handled by the WebStreams API, so when you want to "cancel" a download or upload, you just throw in the function which is consuming or creating the actual data which will reject the promise entirely.

However only ReadableStreams are available in some browsers right now, and WritableStreams are still a bit away AFAIK, so it's not possible to do that right now with promises, but i don't think that warrants adding even more features to a language which will most likely never be removed.

I agree. If you're handling objects of that size in single requests, then you're already in footgun territory. Step carefully.

Cancellation is a high-level expression of intent that you no longer care about the result of the operation.

Due to the very nature of asynchronous operations, it is, in general, impossible to even determine which layer will ultimately handle that request (e.g. in your example, whether the POST won't happen, or it'll be aborted, or it's already completed), much less how it'll be handled.

The assumption is that all layers will do their best effort (defined vaguely in a "common sense" way) to service that request.

That is a very useful abstraction to have, and I don't see why JS is special in that regard.

I mean, this isn't new. When you make a POST request in JS a bad network may mean that it gets delivered but errors out on your end. You need to code your application to be robust to this anyway.

This. Absolutely.

Those applications that already aren't robust to this (I sadly assume that is most) aren't going to be helped by cancellation