5 ms·

It's fairly common to cancel an HTTP request. The new fetch API doesn't let you cancel a request as a consequence of this shortcoming of promises, while XMLHttp

It's fairly common to cancel an HTTP request. The new fetch API doesn't let you cancel a request as a consequence of this shortcoming of promises, while XMLHttpRequest does.

pacaro 10y ago
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
- Klathmon 10y ago
  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.
  - pacaro 10y ago
    I agree. If you're handling objects of that size in single requests, then you're already in footgun territory. Step carefully.
- Manishearth 10y ago
  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.
  - pacaro 10y ago
    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
- int_19h 10y ago
  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.
deleted 10y ago
[deleted]
webartisan 10y ago
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?

It's fairly common to cancel an HTTP request. The new fetch API doesn't let you cancel a request as a consequence of this shortcoming of promises, while XMLHttpRequest does.

pacaro 10y ago

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

Klathmon 10y ago
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.
- pacaro 10y ago
  I agree. If you're handling objects of that size in single requests, then you're already in footgun territory. Step carefully.
Manishearth 10y ago
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.
- pacaro 10y ago
  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
int_19h 10y ago
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.

deleted 10y ago

[deleted]

webartisan 10y ago

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?